Date: Mon, 1 Feb 2016 23:32:07 +0100 From: Magnus Ihse Bursie <magnus@ihse.net> To: Brian Gardner <openjdk@getsnappy.com> Cc: java@freebsd.org Subject: Re: Helping out with JDK 9 on BSD Message-ID: <AE9C12FF-BB8D-44AE-978E-57E1A23C540A@ihse.net> In-Reply-To: <56AFD7FA.3090103@oracle.com> References: <56ADE7D4.8020107@oracle.com> <56ADE943.6020103@oracle.com> <8B9ACABA-F9B2-4288-9DB5-CA843DE48C34@getsnappy.com> <08F78FBA-70D2-4819-99BB-05476638726C@getsnappy.com> <56AF48F1.4070506@oracle.com> <0B79DC9D-2379-4B42-9923-0ECC7CB28D22@getsnappy.com> <56AFD7FA.3090103@oracle.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Resending.=20 /Magnus > On 2016-02-01 23:11, Magnus Ihse Bursie wrote: > _______________________________________________ > freebsd-java@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-java > To unsubscribe, send any mail to "freebsd-java-unsubscribe@freebsd.org" I'm not sure what happened there. Here is what I sent: > On 2016-02-01 16:46, Brian Gardner wrote: > Hi Magnus, > I=E2=80=99ve been looking into it further and it lead me to a couple of ch= ange sets: > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/469835cd5494 > and then this change set: > http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/f7dc8eebc3f5 >=20 > The second change set titled, Replace ThreadLocalStorage with compiler/la= nguage-based thread-local variables, > seems to add in logic for doing compiler based thread local storage THREAD= _LOCAL_DECL, but fails to actually replace the ThreadLocalStorage usage when= persisting the current thread. I couldn=E2=80=99t understand why you would= want to persist both ways.=20 I believe the reason for this is given in the bug description (https://bugs.= openjdk.java.net/browse/JDK-8132510): "The code underpinning __thread use is not async-signal-safe, which is not r= eally a surprise as pthread_get/setspecific are not designated async-signal-= safe either. [...] So I've reinstated a very basic ThreadLocalStorage class which will only nee= d two implementations: a POSIX one, and a Windows one. This class is always i= nitialized and ThreadLocalStorage::thread() is used from the signal handlers= (as today). " > In any case it seemed harmless, and I=E2=80=99m trying to get gdb working= with my images so I can debug the TLS issue further. =20 >=20 > It sounds like you already have an idea how to fix it though. Any ideas o= r pointers would be greatly appreciated. I think you've dug up about as much as I did. I believe the main cause for t= he problems is JDK-8132510 (the second of your changesets) which rewrote the= entire infrastructure on how TLS is used in hotspot. And this was not teste= d on bsd. I know it took some iterations to get it right on the platforms it= was tested on. I think one approach is to study this changeset more in deta= il on how linux and macosx is handled, which will likely give some hints on w= hat's missing for bsd. It seems you've might have been finding some discrepa= ncies already.=20 The first of your changesets indicate a way this same problem was fixed prev= iously. It seems to me that this fix (creating the key with a restore_thread= _pointer callback) is implemented in JDK-8132510, but maybe it doesn't work.= Perhaps there is some difference in the implementation of this on FreeBSD? = =46rom the manpage for pthread_key_create I read: If, after all the destructors have been called for all non-NULL values with associated destructors, there are still some non-NULL values with associated destructors, then the process is repeated. If, after at lea= st [PTHREAD_DESTRUCTOR_ITERATIONS] iterations of destructor calls for out-= standing non-NULL values, there are still some non-NULL values with ass= o- ciated destructors, the implementation stops calling destructors. It seems that PTHREAD_DESTRUCTOR_ITERATIONS is 4 on FreeBSD. Maybe it's l= arger on other systems? (Checking on my Ubuntu, I read 4 there as well). Hm,= so maybe something is iterating out of control here. I have some ideas of it's cause, at least. I'll provide what info I have. This was (probably) introduced by JDK-8132510 (the second of your changesets= ), which rewrote the entire infrastructure on how TLS is used in hotspot. An= d this was not adapted to bsd. I think one approach is to study this changes= et more in detail on how linux and macosx is handled, which will likely give= some hints on what's missing for bsd. I'm currently trying to recompile with -DUSE_LIBRARY_BASED_TLS_ONLY, to see i= f that modifies the behavior. I don't really think it will, but if it does, i= t'll shed some light on the problem. Another approach is to compile a debug build (configure --enable-debug) and s= ee if this assert is triggered: assert(!_initialized, "initializing TLS more than once!"); /Magnus
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?AE9C12FF-BB8D-44AE-978E-57E1A23C540A>