From owner-freebsd-java@freebsd.org Mon Feb 1 23:02:36 2016 Return-Path: Delivered-To: freebsd-java@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 1D1E9A76FD7 for ; Mon, 1 Feb 2016 23:02:36 +0000 (UTC) (envelope-from magnus@ihse.net) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 03B691223 for ; Mon, 1 Feb 2016 23:02:36 +0000 (UTC) (envelope-from magnus@ihse.net) Received: by mailman.ysv.freebsd.org (Postfix) id 02193A76FD6; Mon, 1 Feb 2016 23:02:36 +0000 (UTC) Delivered-To: java@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 019CDA76FD5 for ; Mon, 1 Feb 2016 23:02:36 +0000 (UTC) (envelope-from magnus@ihse.net) Received: from manu26.manufrog.com (manu26.manufrog.com [67.23.251.125]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id BB5FA1222 for ; Mon, 1 Feb 2016 23:02:35 +0000 (UTC) (envelope-from magnus@ihse.net) Received: from h-217-42.a357.priv.bahnhof.se ([81.170.217.42]:52224 helo=[192.168.7.18]) by manu26.manufrog.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.86) (envelope-from ) id 1aQN10-003IjY-4Z; Mon, 01 Feb 2016 23:32:10 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 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> In-Reply-To: <56AFD7FA.3090103@oracle.com> Mime-Version: 1.0 Message-Id: Cc: java@freebsd.org X-Mailer: iPhone Mail (13A452) From: Magnus Ihse Bursie Subject: Re: Helping out with JDK 9 on BSD Date: Mon, 1 Feb 2016 23:32:07 +0100 To: Brian Gardner X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - manu26.manufrog.com X-AntiAbuse: Original Domain - freebsd.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - ihse.net X-Get-Message-Sender-Via: manu26.manufrog.com: authenticated_id: magnus@ihse.net X-Authenticated-Sender: manu26.manufrog.com: magnus@ihse.net X-Source: X-Source-Args: X-Source-Dir: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-java@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Porting Java to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Feb 2016 23:02:36 -0000 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