From hammad_a17 at yahoo.com  Sat Mar  5 10:43:15 2016
From: hammad_a17 at yahoo.com (AMAL.Adnan HAMMAD)
Date: Sat, 5 Mar 2016 14:43:15 +0400
Subject: mrs Amal hammad#pobox:300974
Message-ID: <79ACC7BE-A038-4B29-821B-8BCDEE28AB5D@yahoo.com>



Amal Adnan ibrahim Hammad#UCC1-207 sole owner of SFT#Entity#000 000 000 tel:00971552111890
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/bsd-port-dev/attachments/20160305/8c1a7623/attachment.html>

From openjdk at getsnappy.com  Thu Mar 17 05:00:40 2016
From: openjdk at getsnappy.com (Brian Gardner)
Date: Wed, 16 Mar 2016 22:00:40 -0700
Subject: openjdk9 on Freebsd
In-Reply-To: <BB1FE5B5-8265-427F-8A2A-8299C92CE16B@getsnappy.com>
References: <BB1FE5B5-8265-427F-8A2A-8299C92CE16B@getsnappy.com>
Message-ID: <C54A1462-6913-41F9-801B-5F39EFEA8E56@getsnappy.com>

Is anyone else interested in getting these changes into the jdk9 mainstream?  It?s been over a month without a response.


> On Feb 15, 2016, at 6:13 PM, Brian Gardner <openjdk at getsnappy.com> wrote:
> 
> Hello,
> I?ve been working on getting jdk9 to build cleanly and compile and run HelloWorld cleanly on Freebsd.  This was following up on a couple patches released by Magnus Ipse Bursie who works at Oracle.  He is interested in getting some of these changes integrated into to jdk9 mainline.
> 
> Here are his patches:
> WebRev for build changes: 
> http://cr.openjdk.java.net/~ihse/JDK-8147795-build-system-support-for-bsd/webrev.01 <http://cr.openjdk.java.net/~ihse/JDK-8147795-build-system-support-for-bsd/webrev.01> 
> 
> To make this compile properly on BSD, some source code changes are also needed. Here is a simple patch that fixes the compilation show-stoppers. Note that this is *not* part of this bug. 
> http://cr.openjdk.java.net/~ihse/JDK-8147795_addendum-bsd-source-patches/webrev.01/ <http://cr.openjdk.java.net/~ihse/JDK-8147795_addendum-bsd-source-patches/webrev.01/>
> 
> 
> 
> Here are my patches which supplement Magnus?s:
> 
> porting build_vm_def.sh from bsd-port/jdk8 repo, to fix NM errors during build
> http://brian.timestudybuddy.com/webrev/hotspot__NM/webrev/ <http://brian.timestudybuddy.com/webrev/hotspot__NM/webrev/>
> Add SUPPORT_RESERVED_STACK_AREA flag for all BSD's
> http://brian.timestudybuddy.com/webrev/hotspot__SUPPORT_RESERVED_STACK_AREA/webrev/ <http://brian.timestudybuddy.com/webrev/hotspot__SUPPORT_RESERVED_STACK_AREA/webrev/>
> porting getthreadid logic from bsd-port/jdk8. calling syscall(SYS_thr_self) caused pthread_setspecific to be cleared.
> http://brian.timestudybuddy.com/webrev/hotspot__os_bsd_cpp__getthreadid/webrev/ <http://brian.timestudybuddy.com/webrev/hotspot__os_bsd_cpp__getthreadid/webrev/>
> adding in servicability agent ported from bsd-port/jdk8
> http://brian.timestudybuddy.com/webrev/hotspot__sa/webrev/ <http://brian.timestudybuddy.com/webrev/hotspot__sa/webrev/>
> adding classlist.bsd that is identical to classlist.linux, in order to compile
> http://brian.timestudybuddy.com/webrev/jdk__classlist-bsd/webrev/ <http://brian.timestudybuddy.com/webrev/jdk__classlist-bsd/webrev/>
> 
> 
> 
> The next patches where less straightforward.  When running java I was getting a ton of messages like:
> Thread 832744400 has exited with leftover thread-specific data after 4 destructor iterations
> After doing a lot of digging and debugging on Linux, I found the code path for Linux was identical for Freebsd and the cleanup destructor was being executed 4 times just like Freebsd, the difference being that Freebsd would print out this benign warning while Linux would just ignore it.  The problem is that all threads that are created and initialize TLS current thread data, must clean them up by explicitly setting the TLS current thread to null.  I?ve come up with two approaches to accomplish this.
> 
> clean up TLS current thread at end of ::run functions similar to how it's done in openjdk8.
> http://brian.timestudybuddy.com/webrev/hotspot__clear_thread_current/webrev/ <http://brian.timestudybuddy.com/webrev/hotspot__clear_thread_current/webrev/>
> clear current thread before exiting java_start to avoid warnings from leftover pthread_setspecific data
> http://brian.timestudybuddy.com/webrev/hotspot__clear_thread_current_alt/webrev/ <http://brian.timestudybuddy.com/webrev/hotspot__clear_thread_current_alt/webrev/>
> 
> 
> With all these patches I?ve accomplished my initial goal of getting Freebsd to build cleanly and compile and run HelloWorld cleanly on Freebsd
> 
> Thanks,
> Brian Gardner
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/bsd-port-dev/attachments/20160316/803f1bce/attachment-0001.html>

From thomas.stuefe at gmail.com  Thu Mar 17 09:31:15 2016
From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=)
Date: Thu, 17 Mar 2016 10:31:15 +0100
Subject: openjdk9 on Freebsd
In-Reply-To: <C54A1462-6913-41F9-801B-5F39EFEA8E56@getsnappy.com>
References: <BB1FE5B5-8265-427F-8A2A-8299C92CE16B@getsnappy.com>
	<C54A1462-6913-41F9-801B-5F39EFEA8E56@getsnappy.com>
Message-ID: <CAA-vtUwGaAR4ZEqKcrSC=boxE21KVJfi0K_NAPMtPDBAAUqoHQ@mail.gmail.com>

Hi Brian,


> The next patches where less straightforward.  When running java I was
> getting a ton of messages like:
> Thread 832744400 has exited with leftover thread-specific data after 4
> destructor iterations
> After doing a lot of digging and debugging on Linux, I found the code path
> for Linux was identical for Freebsd and the cleanup destructor was being
> executed 4 times just like Freebsd, the difference being that Freebsd would
> print out this benign warning while Linux would just ignore it.  The
> problem is that all threads that are created and initialize TLS current
> thread data, must clean them up by explicitly setting the TLS current
> thread to null.  I?ve come up with two approaches to accomplish this.
>
> clean up TLS current thread at end of ::run functions similar to how it's
> done in openjdk8.
>
> http://brian.timestudybuddy.com/webrev/hotspot__clear_thread_current/webrev/
> clear current thread before exiting java_start to avoid warnings from
> leftover pthread_setspecific data
>
> http://brian.timestudybuddy.com/webrev/hotspot__clear_thread_current_alt/webrev/
>
>
>
I do not think this is a real leak. From what I remember of how the glibc
implements TLS, setting the TLS slot value to NULL would not in itself
delete anything. In VM, this slot keeps the pointer to the current Thread*,
which is correctly deleted at the end of the thread (void
JavaThread::thread_main_inner()).

Digging further, I found the pthread key destructor
"restore_thread_pointer(void* p)" in threadLocalStorage_posix.cpp:

// Restore the thread pointer if the destructor is called. This is in case
// someone from JNI code sets up a destructor with pthread_key_create to run
// detachCurrentThread on thread death. Unless we restore the thread
pointer we
// will hang or crash. When detachCurrentThread is called the key will be
set
// to null and we will not be called again. If detachCurrentThread is never
// called we could loop forever depending on the pthread implementation.
extern "C" void restore_thread_pointer(void* p) {
  ThreadLocalStorage::set_thread((Thread*) p);
}

So, it seems we even reset deliberately the thread pointer to a non-NULL
value. The comment claims that we reset the Thread* value in case there is
another user-provided destructor which runs afterwards and which
does detachCurrentThread () which would require Thread::current() to work.
But there a details I do not understand:

- At this point, should the Thread* object not already be deallocated, so
this would be a dangling pointer anyway?

- Also, according to Posix, this is unspecified. Doc on
pthread_setspecific() states: "Calling pthread_setspecific() from a
thread-specific data destructor routine may result either in lost storage
(after at least PTHREAD_DESTRUCTOR_ITERATIONS attempts at destruction) or
in an infinite loop."

- In jdk8, we did reset the slot value to NULL before Thread exit. So, in
this case detachCurrentThread() from a pthread_key destructor should not
have worked at all.

Could someone from Oracle maybe shed light on this?

Kind Regards, Thomas


With all these patches I?ve accomplished my initial goal of getting Freebsd
> to build cleanly and compile and run HelloWorld cleanly on Freebsd
>
> Thanks,
> Brian Gardner
>
>
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/bsd-port-dev/attachments/20160317/88283e81/attachment.html>

From david.holmes at oracle.com  Fri Mar 18 04:02:29 2016
From: david.holmes at oracle.com (David Holmes)
Date: Fri, 18 Mar 2016 14:02:29 +1000
Subject: openjdk9 on Freebsd
In-Reply-To: <CAA-vtUwGaAR4ZEqKcrSC=boxE21KVJfi0K_NAPMtPDBAAUqoHQ@mail.gmail.com>
References: <CAA-vtUwGaAR4ZEqKcrSC=boxE21KVJfi0K_NAPMtPDBAAUqoHQ@mail.gmail.com>
Message-ID: <56EB7DD5.8090403@oracle.com>

Thomas writes:
> Hi Brian,
>
>
>> The next patches where less straightforward.  When running java I was
>> getting a ton of messages like:
>> Thread 832744400 has exited with leftover thread-specific data after 4
>> destructor iterations
>> After doing a lot of digging and debugging on Linux, I found the code path
>> for Linux was identical for Freebsd and the cleanup destructor was being
>> executed 4 times just like Freebsd, the difference being that Freebsd would
>> print out this benign warning while Linux would just ignore it.  The
>> problem is that all threads that are created and initialize TLS current
>> thread data, must clean them up by explicitly setting the TLS current
>> thread to null.  I?ve come up with two approaches to accomplish this.
>>
>> clean up TLS current thread at end of ::run functions similar to how it's
>> done in openjdk8.
>>
>> http://brian.timestudybuddy.com/webrev/hotspot__clear_thread_current/webrev/
>> clear current thread before exiting java_start to avoid warnings from
>> leftover pthread_setspecific data
>>
>> http://brian.timestudybuddy.com/webrev/hotspot__clear_thread_current_alt/webrev/
>>
>>
>>
> I do not think this is a real leak. From what I remember of how the glibc
> implements TLS, setting the TLS slot value to NULL would not in itself
> delete anything. In VM, this slot keeps the pointer to the current Thread*,
> which is correctly deleted at the end of the thread (void
> JavaThread::thread_main_inner()).
>
> Digging further, I found the pthread key destructor
> "restore_thread_pointer(void* p)" in threadLocalStorage_posix.cpp:
>
> // Restore the thread pointer if the destructor is called. This is in case
> // someone from JNI code sets up a destructor with pthread_key_create to run
> // detachCurrentThread on thread death. Unless we restore the thread
> pointer we
> // will hang or crash. When detachCurrentThread is called the key will be
> set
> // to null and we will not be called again. If detachCurrentThread is never
> // called we could loop forever depending on the pthread implementation.
> extern "C" void restore_thread_pointer(void* p) {
>   ThreadLocalStorage::set_thread((Thread*) p);
> }
>
> So, it seems we even reset deliberately the thread pointer to a non-NULL
> value. The comment claims that we reset the Thread* value in case there is
> another user-provided destructor which runs afterwards and which
> does detachCurrentThread () which would require Thread::current() to work.
> But there a details I do not understand:
>
> - At this point, should the Thread* object not already be deallocated, so
> this would be a dangling pointer anyway?
>
> - Also, according to Posix, this is unspecified. Doc on
> pthread_setspecific() states: "Calling pthread_setspecific() from a
> thread-specific data destructor routine may result either in lost storage
> (after at least PTHREAD_DESTRUCTOR_ITERATIONS attempts at destruction) or
> in an infinite loop."
>
> - In jdk8, we did reset the slot value to NULL before Thread exit. So, in
> this case detachCurrentThread() from a pthread_key destructor should not
> have worked at all.
>
> Could someone from Oracle maybe shed light on this?

Please see the following discussion and bug report:

http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2014-February/010759.html

Note I don't follow this list so please include me directly in any 
follow-ups if needed.

Thanks,
David

From openjdk at getsnappy.com  Fri Mar 18 16:58:47 2016
From: openjdk at getsnappy.com (Brian Gardner)
Date: Fri, 18 Mar 2016 09:58:47 -0700
Subject: openjdk9 on Freebsd
In-Reply-To: <56EB7DD5.8090403@oracle.com>
References: <CAA-vtUwGaAR4ZEqKcrSC=boxE21KVJfi0K_NAPMtPDBAAUqoHQ@mail.gmail.com>
	<56EB7DD5.8090403@oracle.com>
Message-ID: <3559E764-BEB6-4C88-998C-56A3F06731B5@getsnappy.com>

That explains the destructor.  Looking at the initial change set that came out of this bug, we also see the first spot where we set the TLS current thread is set to NULL http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/469835cd5494 <http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/469835cd5494>

So I think it?s safe to say that setting TLS current thread to NULL is the correct way to set the state to "destroying thread" and preventing the destructor from looping indefinitely.

Here is the relevant comment from Andreas:

--------------------------------
I did find a way to change the JVM to workaround this problem:
By creating a destructor for the thread pointer TLS we can restore the 
value after pthread has set it to NULL.
Then when the native code destructor is run the thread pointer is still 
intact.

Restoring a value in a pthread TLS is explicitly supported according to 
the man page for pthread_key_create, and it will call the destructor for 
the restored value again.
One would have to keep some extra state to make sure the destructor is 
only called twice, since a pthread implementation is allowed to call the 
destructor infinite times as long as the value is restored.

On my system pthread calls the destructor a maximum of four times, so 
the attached JVM patch was sufficient as a proof of concept.
????????????????


> On Mar 17, 2016, at 9:02 PM, David Holmes <david.holmes at oracle.com> wrote:
> 
> Thomas writes:
>> Hi Brian,
>> 
>> 
>>> The next patches where less straightforward.  When running java I was
>>> getting a ton of messages like:
>>> Thread 832744400 has exited with leftover thread-specific data after 4
>>> destructor iterations
>>> After doing a lot of digging and debugging on Linux, I found the code path
>>> for Linux was identical for Freebsd and the cleanup destructor was being
>>> executed 4 times just like Freebsd, the difference being that Freebsd would
>>> print out this benign warning while Linux would just ignore it.  The
>>> problem is that all threads that are created and initialize TLS current
>>> thread data, must clean them up by explicitly setting the TLS current
>>> thread to null.  I?ve come up with two approaches to accomplish this.
>>> 
>>> clean up TLS current thread at end of ::run functions similar to how it's
>>> done in openjdk8.
>>> 
>>> http://brian.timestudybuddy.com/webrev/hotspot__clear_thread_current/webrev/
>>> clear current thread before exiting java_start to avoid warnings from
>>> leftover pthread_setspecific data
>>> 
>>> http://brian.timestudybuddy.com/webrev/hotspot__clear_thread_current_alt/webrev/
>>> 
>>> 
>>> 
>> I do not think this is a real leak. From what I remember of how the glibc
>> implements TLS, setting the TLS slot value to NULL would not in itself
>> delete anything. In VM, this slot keeps the pointer to the current Thread*,
>> which is correctly deleted at the end of the thread (void
>> JavaThread::thread_main_inner()).
>> 
>> Digging further, I found the pthread key destructor
>> "restore_thread_pointer(void* p)" in threadLocalStorage_posix.cpp:
>> 
>> // Restore the thread pointer if the destructor is called. This is in case
>> // someone from JNI code sets up a destructor with pthread_key_create to run
>> // detachCurrentThread on thread death. Unless we restore the thread
>> pointer we
>> // will hang or crash. When detachCurrentThread is called the key will be
>> set
>> // to null and we will not be called again. If detachCurrentThread is never
>> // called we could loop forever depending on the pthread implementation.
>> extern "C" void restore_thread_pointer(void* p) {
>>  ThreadLocalStorage::set_thread((Thread*) p);
>> }
>> 
>> So, it seems we even reset deliberately the thread pointer to a non-NULL
>> value. The comment claims that we reset the Thread* value in case there is
>> another user-provided destructor which runs afterwards and which
>> does detachCurrentThread () which would require Thread::current() to work.
>> But there a details I do not understand:
>> 
>> - At this point, should the Thread* object not already be deallocated, so
>> this would be a dangling pointer anyway?
>> 
>> - Also, according to Posix, this is unspecified. Doc on
>> pthread_setspecific() states: "Calling pthread_setspecific() from a
>> thread-specific data destructor routine may result either in lost storage
>> (after at least PTHREAD_DESTRUCTOR_ITERATIONS attempts at destruction) or
>> in an infinite loop."
>> 
>> - In jdk8, we did reset the slot value to NULL before Thread exit. So, in
>> this case detachCurrentThread() from a pthread_key destructor should not
>> have worked at all.
>> 
>> Could someone from Oracle maybe shed light on this?
> 
> Please see the following discussion and bug report:
> 
> http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2014-February/010759.html
> 
> Note I don't follow this list so please include me directly in any follow-ups if needed.
> 
> Thanks,
> David
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/bsd-port-dev/attachments/20160318/a5269aed/attachment-0001.html>

From david.holmes at oracle.com  Fri Mar 18 21:57:51 2016
From: david.holmes at oracle.com (David Holmes)
Date: Sat, 19 Mar 2016 07:57:51 +1000
Subject: openjdk9 on Freebsd
In-Reply-To: <3559E764-BEB6-4C88-998C-56A3F06731B5@getsnappy.com>
References: <CAA-vtUwGaAR4ZEqKcrSC=boxE21KVJfi0K_NAPMtPDBAAUqoHQ@mail.gmail.com>
	<56EB7DD5.8090403@oracle.com>
	<3559E764-BEB6-4C88-998C-56A3F06731B5@getsnappy.com>
Message-ID: <56EC79DF.80702@oracle.com>

On 19/03/2016 2:58 AM, Brian Gardner wrote:
> That explains the destructor.  Looking at the initial change set that
> came out of this bug, we also see the first spot where we set the TLS
> current thread is set to NULL
> http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/469835cd5494

Are you referring to:

+  // Thread destructor usually does this.
+  ThreadLocalStorage::set_thread(NULL);

? That's only there because the VMThread destructor is never called.

> So I think it?s safe to say that setting TLS current thread to NULL is
> the correct way to set the state to "destroying thread" and preventing
> the destructor from looping indefinitely.

I'm not sure exactly what you mean.

>
> Here is the relevant comment from Andreas:
>
> --------------------------------
>
> I did find a way to change the JVM to workaround this problem:
> By creating a destructor for the thread pointer TLS we can restore the
> value after pthread has set it to NULL.
> Then when the native code destructor is run the thread pointer is still
> intact.
>
> Restoring a value in a pthread TLS is explicitly supported according to
> the man page for pthread_key_create, and it will call the destructor for
> the restored value again.
> One would have to keep some extra state to make sure the destructor is
> only called twice, since a pthread implementation is allowed to call the
> destructor infinite times as long as the value is restored.
>
> On my system pthread calls the destructor a maximum of four times, so
> the attached JVM patch was sufficient as a proof of concept.
>
> ????????????????

We implemented the basic patch, we don't do anything to ensure it was 
called at most twice. We expect all well behaving apps to detach threads 
from the JVM before they terminate.

David
-----

>
>> On Mar 17, 2016, at 9:02 PM, David Holmes <david.holmes at oracle.com
>> <mailto:david.holmes at oracle.com>> wrote:
>>
>> Thomas writes:
>>> Hi Brian,
>>>
>>>
>>>> The next patches where less straightforward.  When running java I was
>>>> getting a ton of messages like:
>>>> Thread 832744400 has exited with leftover thread-specific data after 4
>>>> destructor iterations
>>>> After doing a lot of digging and debugging on Linux, I found the
>>>> code path
>>>> for Linux was identical for Freebsd and the cleanup destructor was being
>>>> executed 4 times just like Freebsd, the difference being that
>>>> Freebsd would
>>>> print out this benign warning while Linux would just ignore it.  The
>>>> problem is that all threads that are created and initialize TLS current
>>>> thread data, must clean them up by explicitly setting the TLS current
>>>> thread to null.  I?ve come up with two approaches to accomplish this.
>>>>
>>>> clean up TLS current thread at end of ::run functions similar to how
>>>> it's
>>>> done in openjdk8.
>>>>
>>>> http://brian.timestudybuddy.com/webrev/hotspot__clear_thread_current/webrev/
>>>> clear current thread before exiting java_start to avoid warnings from
>>>> leftover pthread_setspecific data
>>>>
>>>> http://brian.timestudybuddy.com/webrev/hotspot__clear_thread_current_alt/webrev/
>>>>
>>>>
>>>>
>>> I do not think this is a real leak. From what I remember of how the glibc
>>> implements TLS, setting the TLS slot value to NULL would not in itself
>>> delete anything. In VM, this slot keeps the pointer to the current
>>> Thread*,
>>> which is correctly deleted at the end of the thread (void
>>> JavaThread::thread_main_inner()).
>>>
>>> Digging further, I found the pthread key destructor
>>> "restore_thread_pointer(void* p)" in threadLocalStorage_posix.cpp:
>>>
>>> // Restore the thread pointer if the destructor is called. This is in
>>> case
>>> // someone from JNI code sets up a destructor with pthread_key_create
>>> to run
>>> // detachCurrentThread on thread death. Unless we restore the thread
>>> pointer we
>>> // will hang or crash. When detachCurrentThread is called the key will be
>>> set
>>> // to null and we will not be called again. If detachCurrentThread is
>>> never
>>> // called we could loop forever depending on the pthread implementation.
>>> extern "C" void restore_thread_pointer(void* p) {
>>>  ThreadLocalStorage::set_thread((Thread*) p);
>>> }
>>>
>>> So, it seems we even reset deliberately the thread pointer to a non-NULL
>>> value. The comment claims that we reset the Thread* value in case
>>> there is
>>> another user-provided destructor which runs afterwards and which
>>> does detachCurrentThread () which would require Thread::current() to
>>> work.
>>> But there a details I do not understand:
>>>
>>> - At this point, should the Thread* object not already be deallocated, so
>>> this would be a dangling pointer anyway?
>>>
>>> - Also, according to Posix, this is unspecified. Doc on
>>> pthread_setspecific() states: "Calling pthread_setspecific() from a
>>> thread-specific data destructor routine may result either in lost storage
>>> (after at least PTHREAD_DESTRUCTOR_ITERATIONS attempts at destruction) or
>>> in an infinite loop."
>>>
>>> - In jdk8, we did reset the slot value to NULL before Thread exit. So, in
>>> this case detachCurrentThread() from a pthread_key destructor should not
>>> have worked at all.
>>>
>>> Could someone from Oracle maybe shed light on this?
>>
>> Please see the following discussion and bug report:
>>
>> http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2014-February/010759.html
>>
>> Note I don't follow this list so please include me directly in any
>> follow-ups if needed.
>>
>> Thanks,
>> David
>>
>

From openjdk at getsnappy.com  Sun Mar 20 06:46:33 2016
From: openjdk at getsnappy.com (Brian Gardner)
Date: Sat, 19 Mar 2016 23:46:33 -0700
Subject: openjdk9 on Freebsd
In-Reply-To: <56EC79DF.80702@oracle.com>
References: <CAA-vtUwGaAR4ZEqKcrSC=boxE21KVJfi0K_NAPMtPDBAAUqoHQ@mail.gmail.com>
	<56EB7DD5.8090403@oracle.com>
	<3559E764-BEB6-4C88-998C-56A3F06731B5@getsnappy.com>
	<56EC79DF.80702@oracle.com>
Message-ID: <6E1C2288-1C3F-4BEB-9945-9C18F89A8FFF@getsnappy.com>

Yes, I was referring to the call to ThreadLocalStorage::set_thread(NULL).

The problem I'm trying to resolve are the pthread destructors being called repeadly.  On linux this isn?t a problem because the destructor is called 4 times then silently gives up.  On FreeBSD the destructor is called 4 times then prints a warning to stderr, which is a problem, although it is harmless.

The message below from the original thread states there are three scenarios threads fall into in regards to the initial commit.  The third scenario is the problem scenario I just mentioned and while it is ok on Linux, it isn?t ok on Freebsd because of the warnings to stderr.

http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2014-February/010796.html <http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2014-February/010796.html>
I didn?t articulate it very well but I was trying to say that calling ThreadLocalStorage::set_thread(NULL) durning thread cleanup is the proper way to prevent the destructor from being called repeatedly.  I actually can?t think of an alternate way to do this.
In openjdk8 all threads clean themselves by calling ThreadLocalStorage::set_thread(NULL).  I?m going to do some more research to locate the change sets for these calls.  Perhaps they are isolated to bsd-port branch.  I?ll let everyone know what I find.

Kind regards,
Brian Gardner


> On Mar 18, 2016, at 2:57 PM, David Holmes <david.holmes at oracle.com> wrote:
> 
> On 19/03/2016 2:58 AM, Brian Gardner wrote:
>> That explains the destructor.  Looking at the initial change set that
>> came out of this bug, we also see the first spot where we set the TLS
>> current thread is set to NULL
>> http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/469835cd5494 <http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/469835cd5494>
> 
> Are you referring to:
> 
> +  // Thread destructor usually does this.
> +  ThreadLocalStorage::set_thread(NULL);
> 
> ? That's only there because the VMThread destructor is never called.
> 
>> So I think it?s safe to say that setting TLS current thread to NULL is
>> the correct way to set the state to "destroying thread" and preventing
>> the destructor from looping indefinitely.
> 
> I'm not sure exactly what you mean.
> 
>> 
>> Here is the relevant comment from Andreas:
>> 
>> --------------------------------
>> 
>> I did find a way to change the JVM to workaround this problem:
>> By creating a destructor for the thread pointer TLS we can restore the
>> value after pthread has set it to NULL.
>> Then when the native code destructor is run the thread pointer is still
>> intact.
>> 
>> Restoring a value in a pthread TLS is explicitly supported according to
>> the man page for pthread_key_create, and it will call the destructor for
>> the restored value again.
>> One would have to keep some extra state to make sure the destructor is
>> only called twice, since a pthread implementation is allowed to call the
>> destructor infinite times as long as the value is restored.
>> 
>> On my system pthread calls the destructor a maximum of four times, so
>> the attached JVM patch was sufficient as a proof of concept.
>> 
>> ????????????????
> 
> We implemented the basic patch, we don't do anything to ensure it was called at most twice. We expect all well behaving apps to detach threads from the JVM before they terminate.
> 
> David
> -----
> 
>> 
>>> On Mar 17, 2016, at 9:02 PM, David Holmes <david.holmes at oracle.com <mailto:david.holmes at oracle.com>
>>> <mailto:david.holmes at oracle.com <mailto:david.holmes at oracle.com>>> wrote:
>>> 
>>> Thomas writes:
>>>> Hi Brian,
>>>> 
>>>> 
>>>>> The next patches where less straightforward.  When running java I was
>>>>> getting a ton of messages like:
>>>>> Thread 832744400 has exited with leftover thread-specific data after 4
>>>>> destructor iterations
>>>>> After doing a lot of digging and debugging on Linux, I found the
>>>>> code path
>>>>> for Linux was identical for Freebsd and the cleanup destructor was being
>>>>> executed 4 times just like Freebsd, the difference being that
>>>>> Freebsd would
>>>>> print out this benign warning while Linux would just ignore it.  The
>>>>> problem is that all threads that are created and initialize TLS current
>>>>> thread data, must clean them up by explicitly setting the TLS current
>>>>> thread to null.  I?ve come up with two approaches to accomplish this.
>>>>> 
>>>>> clean up TLS current thread at end of ::run functions similar to how
>>>>> it's
>>>>> done in openjdk8.
>>>>> 
>>>>> http://brian.timestudybuddy.com/webrev/hotspot__clear_thread_current/webrev/
>>>>> clear current thread before exiting java_start to avoid warnings from
>>>>> leftover pthread_setspecific data
>>>>> 
>>>>> http://brian.timestudybuddy.com/webrev/hotspot__clear_thread_current_alt/webrev/
>>>>> 
>>>>> 
>>>>> 
>>>> I do not think this is a real leak. From what I remember of how the glibc
>>>> implements TLS, setting the TLS slot value to NULL would not in itself
>>>> delete anything. In VM, this slot keeps the pointer to the current
>>>> Thread*,
>>>> which is correctly deleted at the end of the thread (void
>>>> JavaThread::thread_main_inner()).
>>>> 
>>>> Digging further, I found the pthread key destructor
>>>> "restore_thread_pointer(void* p)" in threadLocalStorage_posix.cpp:
>>>> 
>>>> // Restore the thread pointer if the destructor is called. This is in
>>>> case
>>>> // someone from JNI code sets up a destructor with pthread_key_create
>>>> to run
>>>> // detachCurrentThread on thread death. Unless we restore the thread
>>>> pointer we
>>>> // will hang or crash. When detachCurrentThread is called the key will be
>>>> set
>>>> // to null and we will not be called again. If detachCurrentThread is
>>>> never
>>>> // called we could loop forever depending on the pthread implementation.
>>>> extern "C" void restore_thread_pointer(void* p) {
>>>> ThreadLocalStorage::set_thread((Thread*) p);
>>>> }
>>>> 
>>>> So, it seems we even reset deliberately the thread pointer to a non-NULL
>>>> value. The comment claims that we reset the Thread* value in case
>>>> there is
>>>> another user-provided destructor which runs afterwards and which
>>>> does detachCurrentThread () which would require Thread::current() to
>>>> work.
>>>> But there a details I do not understand:
>>>> 
>>>> - At this point, should the Thread* object not already be deallocated, so
>>>> this would be a dangling pointer anyway?
>>>> 
>>>> - Also, according to Posix, this is unspecified. Doc on
>>>> pthread_setspecific() states: "Calling pthread_setspecific() from a
>>>> thread-specific data destructor routine may result either in lost storage
>>>> (after at least PTHREAD_DESTRUCTOR_ITERATIONS attempts at destruction) or
>>>> in an infinite loop."
>>>> 
>>>> - In jdk8, we did reset the slot value to NULL before Thread exit. So, in
>>>> this case detachCurrentThread() from a pthread_key destructor should not
>>>> have worked at all.
>>>> 
>>>> Could someone from Oracle maybe shed light on this?
>>> 
>>> Please see the following discussion and bug report:
>>> 
>>> http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2014-February/010759.html
>>> 
>>> Note I don't follow this list so please include me directly in any
>>> follow-ups if needed.
>>> 
>>> Thanks,
>>> David

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/bsd-port-dev/attachments/20160319/a97ea2de/attachment-0001.html>

From openjdk at getsnappy.com  Sun Mar 20 18:53:25 2016
From: openjdk at getsnappy.com (Brian Gardner)
Date: Sun, 20 Mar 2016 11:53:25 -0700
Subject: openjdk9 on Freebsd
In-Reply-To: <6E1C2288-1C3F-4BEB-9945-9C18F89A8FFF@getsnappy.com>
References: <CAA-vtUwGaAR4ZEqKcrSC=boxE21KVJfi0K_NAPMtPDBAAUqoHQ@mail.gmail.com>
	<56EB7DD5.8090403@oracle.com>
	<3559E764-BEB6-4C88-998C-56A3F06731B5@getsnappy.com>
	<56EC79DF.80702@oracle.com>
	<6E1C2288-1C3F-4BEB-9945-9C18F89A8FFF@getsnappy.com>
Message-ID: <ED3FDF59-7617-4043-A28A-D6510713860C@getsnappy.com>

I looked into the origination of other calls to set_thread(NULL) in openjdk8.  

hotspot/src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepThread.cpp:163:  ThreadLocalStorage::set_thread(NULL);
hotspot/src/share/vm/gc_implementation/shared/concurrentGCThread.cpp:91:  ThreadLocalStorage::set_thread(NULL);
hotspot/src/share/vm/runtime/thread.cpp:1351:  ThreadLocalStorage::set_thread(NULL);
These are use cases where set_thread(NULL) was called roughly towards the end of the threads run() method.  Annotating them showed they?ve been around prior to being open sourced.  At some point in time there was an effort made to ensure set_thread(NULL) was always called on all threads, and there is a degradation in openjdk9 in these regards.

If cleaning things up in the Thread destructor (Thread::~Thread) worked on all platforms, it would be a clean way to handle the cleanup.  But since this doesn?t get called on all platforms, this logic should have been moved to JavaThread::run().  WatcherThread::run initializes it?s TLS and cleans it up, why not have JavaThread::run() do the same?  I don?t like JavaThread::run leaving it up to all it?s implementations to clean themselves up.

Brian Gardner


> On Mar 19, 2016, at 11:46 PM, Brian Gardner <openjdk at getsnappy.com> wrote:
> 
> Yes, I was referring to the call to ThreadLocalStorage::set_thread(NULL).
> 
> The problem I'm trying to resolve are the pthread destructors being called repeadly.  On linux this isn?t a problem because the destructor is called 4 times then silently gives up.  On FreeBSD the destructor is called 4 times then prints a warning to stderr, which is a problem, although it is harmless.
> 
> The message below from the original thread states there are three scenarios threads fall into in regards to the initial commit.  The third scenario is the problem scenario I just mentioned and while it is ok on Linux, it isn?t ok on Freebsd because of the warnings to stderr.
> 
> http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2014-February/010796.html <http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2014-February/010796.html>
> I didn?t articulate it very well but I was trying to say that calling ThreadLocalStorage::set_thread(NULL) durning thread cleanup is the proper way to prevent the destructor from being called repeatedly.  I actually can?t think of an alternate way to do this.
> In openjdk8 all threads clean themselves by calling ThreadLocalStorage::set_thread(NULL).  I?m going to do some more research to locate the change sets for these calls.  Perhaps they are isolated to bsd-port branch.  I?ll let everyone know what I find.
> 
> Kind regards,
> Brian Gardner
> 
> 
>> On Mar 18, 2016, at 2:57 PM, David Holmes <david.holmes at oracle.com <mailto:david.holmes at oracle.com>> wrote:
>> 
>> On 19/03/2016 2:58 AM, Brian Gardner wrote:
>>> That explains the destructor.  Looking at the initial change set that
>>> came out of this bug, we also see the first spot where we set the TLS
>>> current thread is set to NULL
>>> http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/469835cd5494 <http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/469835cd5494>
>> 
>> Are you referring to:
>> 
>> +  // Thread destructor usually does this.
>> +  ThreadLocalStorage::set_thread(NULL);
>> 
>> ? That's only there because the VMThread destructor is never called.
>> 
>>> So I think it?s safe to say that setting TLS current thread to NULL is
>>> the correct way to set the state to "destroying thread" and preventing
>>> the destructor from looping indefinitely.
>> 
>> I'm not sure exactly what you mean.
>> 
>>> 
>>> Here is the relevant comment from Andreas:
>>> 
>>> --------------------------------
>>> 
>>> I did find a way to change the JVM to workaround this problem:
>>> By creating a destructor for the thread pointer TLS we can restore the
>>> value after pthread has set it to NULL.
>>> Then when the native code destructor is run the thread pointer is still
>>> intact.
>>> 
>>> Restoring a value in a pthread TLS is explicitly supported according to
>>> the man page for pthread_key_create, and it will call the destructor for
>>> the restored value again.
>>> One would have to keep some extra state to make sure the destructor is
>>> only called twice, since a pthread implementation is allowed to call the
>>> destructor infinite times as long as the value is restored.
>>> 
>>> On my system pthread calls the destructor a maximum of four times, so
>>> the attached JVM patch was sufficient as a proof of concept.
>>> 
>>> ????????????????
>> 
>> We implemented the basic patch, we don't do anything to ensure it was called at most twice. We expect all well behaving apps to detach threads from the JVM before they terminate.
>> 
>> David
>> -----
>> 
>>> 
>>>> On Mar 17, 2016, at 9:02 PM, David Holmes <david.holmes at oracle.com <mailto:david.holmes at oracle.com>
>>>> <mailto:david.holmes at oracle.com <mailto:david.holmes at oracle.com>>> wrote:
>>>> 
>>>> Thomas writes:
>>>>> Hi Brian,
>>>>> 
>>>>> 
>>>>>> The next patches where less straightforward.  When running java I was
>>>>>> getting a ton of messages like:
>>>>>> Thread 832744400 has exited with leftover thread-specific data after 4
>>>>>> destructor iterations
>>>>>> After doing a lot of digging and debugging on Linux, I found the
>>>>>> code path
>>>>>> for Linux was identical for Freebsd and the cleanup destructor was being
>>>>>> executed 4 times just like Freebsd, the difference being that
>>>>>> Freebsd would
>>>>>> print out this benign warning while Linux would just ignore it.  The
>>>>>> problem is that all threads that are created and initialize TLS current
>>>>>> thread data, must clean them up by explicitly setting the TLS current
>>>>>> thread to null.  I?ve come up with two approaches to accomplish this.
>>>>>> 
>>>>>> clean up TLS current thread at end of ::run functions similar to how
>>>>>> it's
>>>>>> done in openjdk8.
>>>>>> 
>>>>>> http://brian.timestudybuddy.com/webrev/hotspot__clear_thread_current/webrev/ <http://brian.timestudybuddy.com/webrev/hotspot__clear_thread_current/webrev/>
>>>>>> clear current thread before exiting java_start to avoid warnings from
>>>>>> leftover pthread_setspecific data
>>>>>> 
>>>>>> http://brian.timestudybuddy.com/webrev/hotspot__clear_thread_current_alt/webrev/
>>>>>> 
>>>>>> 
>>>>>> 
>>>>> I do not think this is a real leak. From what I remember of how the glibc
>>>>> implements TLS, setting the TLS slot value to NULL would not in itself
>>>>> delete anything. In VM, this slot keeps the pointer to the current
>>>>> Thread*,
>>>>> which is correctly deleted at the end of the thread (void
>>>>> JavaThread::thread_main_inner()).
>>>>> 
>>>>> Digging further, I found the pthread key destructor
>>>>> "restore_thread_pointer(void* p)" in threadLocalStorage_posix.cpp:
>>>>> 
>>>>> // Restore the thread pointer if the destructor is called. This is in
>>>>> case
>>>>> // someone from JNI code sets up a destructor with pthread_key_create
>>>>> to run
>>>>> // detachCurrentThread on thread death. Unless we restore the thread
>>>>> pointer we
>>>>> // will hang or crash. When detachCurrentThread is called the key will be
>>>>> set
>>>>> // to null and we will not be called again. If detachCurrentThread is
>>>>> never
>>>>> // called we could loop forever depending on the pthread implementation.
>>>>> extern "C" void restore_thread_pointer(void* p) {
>>>>> ThreadLocalStorage::set_thread((Thread*) p);
>>>>> }
>>>>> 
>>>>> So, it seems we even reset deliberately the thread pointer to a non-NULL
>>>>> value. The comment claims that we reset the Thread* value in case
>>>>> there is
>>>>> another user-provided destructor which runs afterwards and which
>>>>> does detachCurrentThread () which would require Thread::current() to
>>>>> work.
>>>>> But there a details I do not understand:
>>>>> 
>>>>> - At this point, should the Thread* object not already be deallocated, so
>>>>> this would be a dangling pointer anyway?
>>>>> 
>>>>> - Also, according to Posix, this is unspecified. Doc on
>>>>> pthread_setspecific() states: "Calling pthread_setspecific() from a
>>>>> thread-specific data destructor routine may result either in lost storage
>>>>> (after at least PTHREAD_DESTRUCTOR_ITERATIONS attempts at destruction) or
>>>>> in an infinite loop."
>>>>> 
>>>>> - In jdk8, we did reset the slot value to NULL before Thread exit. So, in
>>>>> this case detachCurrentThread() from a pthread_key destructor should not
>>>>> have worked at all.
>>>>> 
>>>>> Could someone from Oracle maybe shed light on this?
>>>> 
>>>> Please see the following discussion and bug report:
>>>> 
>>>> http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2014-February/010759.html <http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2014-February/010759.html>
>>>> 
>>>> Note I don't follow this list so please include me directly in any
>>>> follow-ups if needed.
>>>> 
>>>> Thanks,
>>>> David
> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/bsd-port-dev/attachments/20160320/407a4c02/attachment-0001.html>

From david.holmes at oracle.com  Sun Mar 20 21:59:55 2016
From: david.holmes at oracle.com (David Holmes)
Date: Mon, 21 Mar 2016 07:59:55 +1000
Subject: openjdk9 on Freebsd
In-Reply-To: <6E1C2288-1C3F-4BEB-9945-9C18F89A8FFF@getsnappy.com>
References: <CAA-vtUwGaAR4ZEqKcrSC=boxE21KVJfi0K_NAPMtPDBAAUqoHQ@mail.gmail.com>
	<56EB7DD5.8090403@oracle.com>
	<3559E764-BEB6-4C88-998C-56A3F06731B5@getsnappy.com>
	<56EC79DF.80702@oracle.com>
	<6E1C2288-1C3F-4BEB-9945-9C18F89A8FFF@getsnappy.com>
Message-ID: <56EF1D5B.6050605@oracle.com>

On 20/03/2016 4:46 PM, Brian Gardner wrote:
> Yes, I was referring to the call to ThreadLocalStorage::set_thread(NULL).
>
> The problem I'm trying to resolve are the pthread destructors being
> called repeadly.  On linux this isn?t a problem because the destructor
> is called 4 times then silently gives up.  On FreeBSD the destructor is
> called 4 times then prints a warning to stderr, which is a problem,
> although it is harmless.
>
> The message below from the original thread states there are three
> scenarios threads fall into in regards to the initial commit. The third
> scenario is the problem scenario I just mentioned and while it is ok on
> Linux, it isn?t ok on Freebsd because of the warnings to stderr.
>
> http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2014-February/010796.html
>
> I didn?t articulate it very well but I was trying to say that calling
> ThreadLocalStorage::set_thread(NULL) durning thread cleanup is the
> proper way to prevent the destructor from being called repeatedly.  I
> actually can?t think of an alternate way to do this.
>
> In openjdk8 all threads clean themselves by calling
> ThreadLocalStorage::set_thread(NULL). I?m going to do some more research
> to locate the change sets for these calls. Perhaps they are isolated to
> bsd-port branch. I?ll let everyone know what I find.

Ah now I see what you are referring to. In JDK 8 we call 
set_thread(NULL) as part of the Thread destructor. We also call it 
explicitly on the VMThread because it's destructor is never executed.

In JDK 9 we also call set_thread(NULL) as part of the Thread destructor 
(now inside Thread::clear_thread_current) but the VMThread does not call 
this. That was a change I introduced with:

https://bugs.openjdk.java.net/browse/JDK-8132510

"Replace ThreadLocalStorage with compiler/language-based thread-local 
variables"

I did not see the point in clearing TLS for the VMThread because the 
primary purpose of that was to allow for threads detaching or 
terminating and the VMThread does neither. I don't quite understand how 
the TLS destructor gets involved in this case - does process termination 
call TLS destructors on existing threads ??

Anyway it should be harmless to add back a call to 
Thread::clear_thread_current() where previously we had:

   // Thread destructor usually does this.
   ThreadLocalStorage::set_thread(NULL);

I will file a bug for that.

Thanks,
David
-----


> Kind regards,
> Brian Gardner
>
>
>> On Mar 18, 2016, at 2:57 PM, David Holmes <david.holmes at oracle.com
>> <mailto:david.holmes at oracle.com>> wrote:
>>
>> On 19/03/2016 2:58 AM, Brian Gardner wrote:
>>> That explains the destructor.  Looking at the initial change set that
>>> came out of this bug, we also see the first spot where we set the TLS
>>> current thread is set to NULL
>>> http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/469835cd5494
>>
>> Are you referring to:
>>
>> +  // Thread destructor usually does this.
>> +  ThreadLocalStorage::set_thread(NULL);
>>
>> ? That's only there because the VMThread destructor is never called.
>>
>>> So I think it?s safe to say that setting TLS current thread to NULL is
>>> the correct way to set the state to "destroying thread" and preventing
>>> the destructor from looping indefinitely.
>>
>> I'm not sure exactly what you mean.
>>
>>>
>>> Here is the relevant comment from Andreas:
>>>
>>> --------------------------------
>>>
>>> I did find a way to change the JVM to workaround this problem:
>>> By creating a destructor for the thread pointer TLS we can restore the
>>> value after pthread has set it to NULL.
>>> Then when the native code destructor is run the thread pointer is still
>>> intact.
>>>
>>> Restoring a value in a pthread TLS is explicitly supported according to
>>> the man page for pthread_key_create, and it will call the destructor for
>>> the restored value again.
>>> One would have to keep some extra state to make sure the destructor is
>>> only called twice, since a pthread implementation is allowed to call the
>>> destructor infinite times as long as the value is restored.
>>>
>>> On my system pthread calls the destructor a maximum of four times, so
>>> the attached JVM patch was sufficient as a proof of concept.
>>>
>>> ????????????????
>>
>> We implemented the basic patch, we don't do anything to ensure it was
>> called at most twice. We expect all well behaving apps to detach
>> threads from the JVM before they terminate.
>>
>> David
>> -----
>>
>>>
>>>> On Mar 17, 2016, at 9:02 PM, David Holmes <david.holmes at oracle.com
>>>> <mailto:david.holmes at oracle.com>
>>>> <mailto:david.holmes at oracle.com>> wrote:
>>>>
>>>> Thomas writes:
>>>>> Hi Brian,
>>>>>
>>>>>
>>>>>> The next patches where less straightforward.  When running java I was
>>>>>> getting a ton of messages like:
>>>>>> Thread 832744400 has exited with leftover thread-specific data after 4
>>>>>> destructor iterations
>>>>>> After doing a lot of digging and debugging on Linux, I found the
>>>>>> code path
>>>>>> for Linux was identical for Freebsd and the cleanup destructor was
>>>>>> being
>>>>>> executed 4 times just like Freebsd, the difference being that
>>>>>> Freebsd would
>>>>>> print out this benign warning while Linux would just ignore it.  The
>>>>>> problem is that all threads that are created and initialize TLS
>>>>>> current
>>>>>> thread data, must clean them up by explicitly setting the TLS current
>>>>>> thread to null.  I?ve come up with two approaches to accomplish this.
>>>>>>
>>>>>> clean up TLS current thread at end of ::run functions similar to how
>>>>>> it's
>>>>>> done in openjdk8.
>>>>>>
>>>>>> http://brian.timestudybuddy.com/webrev/hotspot__clear_thread_current/webrev/
>>>>>> clear current thread before exiting java_start to avoid warnings from
>>>>>> leftover pthread_setspecific data
>>>>>>
>>>>>> http://brian.timestudybuddy.com/webrev/hotspot__clear_thread_current_alt/webrev/
>>>>>>
>>>>>>
>>>>>>
>>>>> I do not think this is a real leak. From what I remember of how the
>>>>> glibc
>>>>> implements TLS, setting the TLS slot value to NULL would not in itself
>>>>> delete anything. In VM, this slot keeps the pointer to the current
>>>>> Thread*,
>>>>> which is correctly deleted at the end of the thread (void
>>>>> JavaThread::thread_main_inner()).
>>>>>
>>>>> Digging further, I found the pthread key destructor
>>>>> "restore_thread_pointer(void* p)" in threadLocalStorage_posix.cpp:
>>>>>
>>>>> // Restore the thread pointer if the destructor is called. This is in
>>>>> case
>>>>> // someone from JNI code sets up a destructor with pthread_key_create
>>>>> to run
>>>>> // detachCurrentThread on thread death. Unless we restore the thread
>>>>> pointer we
>>>>> // will hang or crash. When detachCurrentThread is called the key
>>>>> will be
>>>>> set
>>>>> // to null and we will not be called again. If detachCurrentThread is
>>>>> never
>>>>> // called we could loop forever depending on the pthread
>>>>> implementation.
>>>>> extern "C" void restore_thread_pointer(void* p) {
>>>>> ThreadLocalStorage::set_thread((Thread*) p);
>>>>> }
>>>>>
>>>>> So, it seems we even reset deliberately the thread pointer to a
>>>>> non-NULL
>>>>> value. The comment claims that we reset the Thread* value in case
>>>>> there is
>>>>> another user-provided destructor which runs afterwards and which
>>>>> does detachCurrentThread () which would require Thread::current() to
>>>>> work.
>>>>> But there a details I do not understand:
>>>>>
>>>>> - At this point, should the Thread* object not already be
>>>>> deallocated, so
>>>>> this would be a dangling pointer anyway?
>>>>>
>>>>> - Also, according to Posix, this is unspecified. Doc on
>>>>> pthread_setspecific() states: "Calling pthread_setspecific() from a
>>>>> thread-specific data destructor routine may result either in lost
>>>>> storage
>>>>> (after at least PTHREAD_DESTRUCTOR_ITERATIONS attempts at
>>>>> destruction) or
>>>>> in an infinite loop."
>>>>>
>>>>> - In jdk8, we did reset the slot value to NULL before Thread exit.
>>>>> So, in
>>>>> this case detachCurrentThread() from a pthread_key destructor
>>>>> should not
>>>>> have worked at all.
>>>>>
>>>>> Could someone from Oracle maybe shed light on this?
>>>>
>>>> Please see the following discussion and bug report:
>>>>
>>>> http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2014-February/010759.html
>>>>
>>>> Note I don't follow this list so please include me directly in any
>>>> follow-ups if needed.
>>>>
>>>> Thanks,
>>>> David
>

From david.holmes at oracle.com  Sun Mar 20 22:20:42 2016
From: david.holmes at oracle.com (David Holmes)
Date: Mon, 21 Mar 2016 08:20:42 +1000
Subject: openjdk9 on Freebsd
In-Reply-To: <ED3FDF59-7617-4043-A28A-D6510713860C@getsnappy.com>
References: <CAA-vtUwGaAR4ZEqKcrSC=boxE21KVJfi0K_NAPMtPDBAAUqoHQ@mail.gmail.com>
	<56EB7DD5.8090403@oracle.com>
	<3559E764-BEB6-4C88-998C-56A3F06731B5@getsnappy.com>
	<56EC79DF.80702@oracle.com>
	<6E1C2288-1C3F-4BEB-9945-9C18F89A8FFF@getsnappy.com>
	<ED3FDF59-7617-4043-A28A-D6510713860C@getsnappy.com>
Message-ID: <56EF223A.2070604@oracle.com>

Sorry I didn't seem this before my previous reply ...

On 21/03/2016 4:53 AM, Brian Gardner wrote:
> I looked into the origination of other calls to set_thread(NULL) in
> openjdk8.
>
>   * hotspot/src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepThread.cpp:163:
>     ThreadLocalStorage::set_thread(NULL);
>   * hotspot/src/share/vm/gc_implementation/shared/concurrentGCThread.cpp:91:
>     ThreadLocalStorage::set_thread(NULL);
>   * hotspot/src/share/vm/runtime/thread.cpp:1351:
>     ThreadLocalStorage::set_thread(NULL);
>
> These are use cases where set_thread(NULL) was called roughly towards
> the end of the threads run() method.  Annotating them showed they?ve
> been around prior to being open sourced.  At some point in time there
> was an effort made to ensure set_thread(NULL) was always called on all
> threads, and there is a degradation in openjdk9 in these regards.

Any thread that terminates explicitly will do this as part of the Thread 
destructor. For other threads it didn't seem necessary given they would 
terminate only when the process terminated.

> If cleaning things up in the Thread destructor (Thread::~Thread) worked
> on all platforms, it would be a clean way to handle the cleanup.  But
> since this doesn?t get called on all platforms, this logic should have
> been moved to JavaThread::run().  WatcherThread::run initializes it?s
> TLS and cleans it up, why not have JavaThread::run() do the same?  I
> don?t like JavaThread::run leaving it up to all it?s implementations to
> clean themselves up.

This is not a platform specific issue. Thread::~Thread gets called, or 
not, for the same set of threads on all platforms. The VMThread, nor 
those other threads, is not a JavaThread so JavaThread::run does not 
come into it. And for JavaThreads we don't want to do this cleanup in 
JavaThread::run because we may still need to refer to the current 
thread, so it is done during Thread::~Thread when the thread has 
"terminated" as far as the VM is concerned.

The problem at hand only affects threads that never terminate/detach. 
They previously would call set_thread(NULL) (though why is unclear), but 
after my changes they don't. But that can be rectified and as I said I 
will file a bug to handle that.

Please note however I am heading out on vacation in two days so this is 
unlikely to get fixed until I return in a couple of weeks.

Thanks,
David

> Brian Gardner
>
>
>> On Mar 19, 2016, at 11:46 PM, Brian Gardner <openjdk at getsnappy.com
>> <mailto:openjdk at getsnappy.com>> wrote:
>>
>> Yes, I was referring to the call to ThreadLocalStorage::set_thread(NULL).
>>
>> The problem I'm trying to resolve are the pthread destructors being
>> called repeadly.  On linux this isn?t a problem because the destructor
>> is called 4 times then silently gives up.  On FreeBSD the destructor
>> is called 4 times then prints a warning to stderr, which is a problem,
>> although it is harmless.
>>
>> The message below from the original thread states there are three
>> scenarios threads fall into in regards to the initial commit. The
>> third scenario is the problem scenario I just mentioned and while it
>> is ok on Linux, it isn?t ok on Freebsd because of the warnings to stderr.
>>
>> http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2014-February/010796.html
>> I didn?t articulate it very well but I was trying to say that calling
>> ThreadLocalStorage::set_thread(NULL) durning thread cleanup is the
>> proper way to prevent the destructor from being called repeatedly.  I
>> actually can?t think of an alternate way to do this.
>> In openjdk8 all threads clean themselves by calling
>> ThreadLocalStorage::set_thread(NULL). I?m going to do some more
>> research to locate the change sets for these calls. Perhaps they are
>> isolated to bsd-port branch. I?ll let everyone know what I find.
>>
>> Kind regards,
>> Brian Gardner
>>
>>
>>> On Mar 18, 2016, at 2:57 PM, David Holmes <david.holmes at oracle.com
>>> <mailto:david.holmes at oracle.com>> wrote:
>>>
>>> On 19/03/2016 2:58 AM, Brian Gardner wrote:
>>>> That explains the destructor.  Looking at the initial change set that
>>>> came out of this bug, we also see the first spot where we set the TLS
>>>> current thread is set to NULL
>>>> http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/469835cd5494
>>>
>>> Are you referring to:
>>>
>>> +  // Thread destructor usually does this.
>>> +  ThreadLocalStorage::set_thread(NULL);
>>>
>>> ? That's only there because the VMThread destructor is never called.
>>>
>>>> So I think it?s safe to say that setting TLS current thread to NULL is
>>>> the correct way to set the state to "destroying thread" and preventing
>>>> the destructor from looping indefinitely.
>>>
>>> I'm not sure exactly what you mean.
>>>
>>>>
>>>> Here is the relevant comment from Andreas:
>>>>
>>>> --------------------------------
>>>>
>>>> I did find a way to change the JVM to workaround this problem:
>>>> By creating a destructor for the thread pointer TLS we can restore the
>>>> value after pthread has set it to NULL.
>>>> Then when the native code destructor is run the thread pointer is still
>>>> intact.
>>>>
>>>> Restoring a value in a pthread TLS is explicitly supported according to
>>>> the man page for pthread_key_create, and it will call the destructor for
>>>> the restored value again.
>>>> One would have to keep some extra state to make sure the destructor is
>>>> only called twice, since a pthread implementation is allowed to call the
>>>> destructor infinite times as long as the value is restored.
>>>>
>>>> On my system pthread calls the destructor a maximum of four times, so
>>>> the attached JVM patch was sufficient as a proof of concept.
>>>>
>>>> ????????????????
>>>
>>> We implemented the basic patch, we don't do anything to ensure it was
>>> called at most twice. We expect all well behaving apps to detach
>>> threads from the JVM before they terminate.
>>>
>>> David
>>> -----
>>>
>>>>
>>>>> On Mar 17, 2016, at 9:02 PM, David Holmes <david.holmes at oracle.com
>>>>> <mailto:david.holmes at oracle.com>
>>>>> <mailto:david.holmes at oracle.com>> wrote:
>>>>>
>>>>> Thomas writes:
>>>>>> Hi Brian,
>>>>>>
>>>>>>
>>>>>>> The next patches where less straightforward.  When running java I was
>>>>>>> getting a ton of messages like:
>>>>>>> Thread 832744400 has exited with leftover thread-specific data
>>>>>>> after 4
>>>>>>> destructor iterations
>>>>>>> After doing a lot of digging and debugging on Linux, I found the
>>>>>>> code path
>>>>>>> for Linux was identical for Freebsd and the cleanup destructor
>>>>>>> was being
>>>>>>> executed 4 times just like Freebsd, the difference being that
>>>>>>> Freebsd would
>>>>>>> print out this benign warning while Linux would just ignore it.  The
>>>>>>> problem is that all threads that are created and initialize TLS
>>>>>>> current
>>>>>>> thread data, must clean them up by explicitly setting the TLS current
>>>>>>> thread to null.  I?ve come up with two approaches to accomplish this.
>>>>>>>
>>>>>>> clean up TLS current thread at end of ::run functions similar to how
>>>>>>> it's
>>>>>>> done in openjdk8.
>>>>>>>
>>>>>>> http://brian.timestudybuddy.com/webrev/hotspot__clear_thread_current/webrev/
>>>>>>> clear current thread before exiting java_start to avoid warnings from
>>>>>>> leftover pthread_setspecific data
>>>>>>>
>>>>>>> http://brian.timestudybuddy.com/webrev/hotspot__clear_thread_current_alt/webrev/
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>> I do not think this is a real leak. From what I remember of how
>>>>>> the glibc
>>>>>> implements TLS, setting the TLS slot value to NULL would not in itself
>>>>>> delete anything. In VM, this slot keeps the pointer to the current
>>>>>> Thread*,
>>>>>> which is correctly deleted at the end of the thread (void
>>>>>> JavaThread::thread_main_inner()).
>>>>>>
>>>>>> Digging further, I found the pthread key destructor
>>>>>> "restore_thread_pointer(void* p)" in threadLocalStorage_posix.cpp:
>>>>>>
>>>>>> // Restore the thread pointer if the destructor is called. This is in
>>>>>> case
>>>>>> // someone from JNI code sets up a destructor with pthread_key_create
>>>>>> to run
>>>>>> // detachCurrentThread on thread death. Unless we restore the thread
>>>>>> pointer we
>>>>>> // will hang or crash. When detachCurrentThread is called the key
>>>>>> will be
>>>>>> set
>>>>>> // to null and we will not be called again. If detachCurrentThread is
>>>>>> never
>>>>>> // called we could loop forever depending on the pthread
>>>>>> implementation.
>>>>>> extern "C" void restore_thread_pointer(void* p) {
>>>>>> ThreadLocalStorage::set_thread((Thread*) p);
>>>>>> }
>>>>>>
>>>>>> So, it seems we even reset deliberately the thread pointer to a
>>>>>> non-NULL
>>>>>> value. The comment claims that we reset the Thread* value in case
>>>>>> there is
>>>>>> another user-provided destructor which runs afterwards and which
>>>>>> does detachCurrentThread () which would require Thread::current() to
>>>>>> work.
>>>>>> But there a details I do not understand:
>>>>>>
>>>>>> - At this point, should the Thread* object not already be
>>>>>> deallocated, so
>>>>>> this would be a dangling pointer anyway?
>>>>>>
>>>>>> - Also, according to Posix, this is unspecified. Doc on
>>>>>> pthread_setspecific() states: "Calling pthread_setspecific() from a
>>>>>> thread-specific data destructor routine may result either in lost
>>>>>> storage
>>>>>> (after at least PTHREAD_DESTRUCTOR_ITERATIONS attempts at
>>>>>> destruction) or
>>>>>> in an infinite loop."
>>>>>>
>>>>>> - In jdk8, we did reset the slot value to NULL before Thread exit.
>>>>>> So, in
>>>>>> this case detachCurrentThread() from a pthread_key destructor
>>>>>> should not
>>>>>> have worked at all.
>>>>>>
>>>>>> Could someone from Oracle maybe shed light on this?
>>>>>
>>>>> Please see the following discussion and bug report:
>>>>>
>>>>> http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2014-February/010759.html
>>>>>
>>>>> Note I don't follow this list so please include me directly in any
>>>>> follow-ups if needed.
>>>>>
>>>>> Thanks,
>>>>> David
>>
>>
>

From david.holmes at oracle.com  Mon Mar 21 00:45:12 2016
From: david.holmes at oracle.com (David Holmes)
Date: Mon, 21 Mar 2016 10:45:12 +1000
Subject: openjdk9 on Freebsd
In-Reply-To: <56EF223A.2070604@oracle.com>
References: <CAA-vtUwGaAR4ZEqKcrSC=boxE21KVJfi0K_NAPMtPDBAAUqoHQ@mail.gmail.com>
	<56EB7DD5.8090403@oracle.com>
	<3559E764-BEB6-4C88-998C-56A3F06731B5@getsnappy.com>
	<56EC79DF.80702@oracle.com>
	<6E1C2288-1C3F-4BEB-9945-9C18F89A8FFF@getsnappy.com>
	<ED3FDF59-7617-4043-A28A-D6510713860C@getsnappy.com>
	<56EF223A.2070604@oracle.com>
Message-ID: <56EF4418.40909@oracle.com>

A further followup/clarification ...

On 21/03/2016 8:20 AM, David Holmes wrote:
> Sorry I didn't seem this before my previous reply ...
>
> On 21/03/2016 4:53 AM, Brian Gardner wrote:
>> I looked into the origination of other calls to set_thread(NULL) in
>> openjdk8.
>>
>>   *
>> hotspot/src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepThread.cpp:163:
>>
>>     ThreadLocalStorage::set_thread(NULL);
>>   *
>> hotspot/src/share/vm/gc_implementation/shared/concurrentGCThread.cpp:91:
>>     ThreadLocalStorage::set_thread(NULL);
>>   * hotspot/src/share/vm/runtime/thread.cpp:1351:
>>     ThreadLocalStorage::set_thread(NULL);
>>
>> These are use cases where set_thread(NULL) was called roughly towards
>> the end of the threads run() method.  Annotating them showed they?ve
>> been around prior to being open sourced.  At some point in time there
>> was an effort made to ensure set_thread(NULL) was always called on all
>> threads, and there is a degradation in openjdk9 in these regards.
>
> Any thread that terminates explicitly will do this as part of the Thread
> destructor. For other threads it didn't seem necessary given they would
> terminate only when the process terminated.

Some non-JavaThreads can actually terminate but AFAICS fail to ever 
destroy the associated Thread instance. That would seem to be a bug in 
itself. If we did ensure the destructor was called on these threads then 
that was also deal with the removal of the set_thread(NULL). If the 
threads do not terminate however, and are still running when the VM 
terminates, then there is no place to put the "missing" 
set_thread(NULL). Note this applies to Java threads to - any Java thread 
still running at VM termination never has set_thread(NULL) called.

So I'm still somewhat at a loss to understand when a "missing" 
set_thread(NULL) can cause a problem at VM termination?

Thanks,
David

>> If cleaning things up in the Thread destructor (Thread::~Thread) worked
>> on all platforms, it would be a clean way to handle the cleanup.  But
>> since this doesn?t get called on all platforms, this logic should have
>> been moved to JavaThread::run().  WatcherThread::run initializes it?s
>> TLS and cleans it up, why not have JavaThread::run() do the same?  I
>> don?t like JavaThread::run leaving it up to all it?s implementations to
>> clean themselves up.
>
> This is not a platform specific issue. Thread::~Thread gets called, or
> not, for the same set of threads on all platforms. The VMThread, nor
> those other threads, is not a JavaThread so JavaThread::run does not
> come into it. And for JavaThreads we don't want to do this cleanup in
> JavaThread::run because we may still need to refer to the current
> thread, so it is done during Thread::~Thread when the thread has
> "terminated" as far as the VM is concerned.
>
> The problem at hand only affects threads that never terminate/detach.
> They previously would call set_thread(NULL) (though why is unclear), but
> after my changes they don't. But that can be rectified and as I said I
> will file a bug to handle that.
>
> Please note however I am heading out on vacation in two days so this is
> unlikely to get fixed until I return in a couple of weeks.
>
> Thanks,
> David
>
>> Brian Gardner
>>
>>
>>> On Mar 19, 2016, at 11:46 PM, Brian Gardner <openjdk at getsnappy.com
>>> <mailto:openjdk at getsnappy.com>> wrote:
>>>
>>> Yes, I was referring to the call to
>>> ThreadLocalStorage::set_thread(NULL).
>>>
>>> The problem I'm trying to resolve are the pthread destructors being
>>> called repeadly.  On linux this isn?t a problem because the destructor
>>> is called 4 times then silently gives up.  On FreeBSD the destructor
>>> is called 4 times then prints a warning to stderr, which is a problem,
>>> although it is harmless.
>>>
>>> The message below from the original thread states there are three
>>> scenarios threads fall into in regards to the initial commit. The
>>> third scenario is the problem scenario I just mentioned and while it
>>> is ok on Linux, it isn?t ok on Freebsd because of the warnings to
>>> stderr.
>>>
>>> http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2014-February/010796.html
>>>
>>> I didn?t articulate it very well but I was trying to say that calling
>>> ThreadLocalStorage::set_thread(NULL) durning thread cleanup is the
>>> proper way to prevent the destructor from being called repeatedly.  I
>>> actually can?t think of an alternate way to do this.
>>> In openjdk8 all threads clean themselves by calling
>>> ThreadLocalStorage::set_thread(NULL). I?m going to do some more
>>> research to locate the change sets for these calls. Perhaps they are
>>> isolated to bsd-port branch. I?ll let everyone know what I find.
>>>
>>> Kind regards,
>>> Brian Gardner
>>>
>>>
>>>> On Mar 18, 2016, at 2:57 PM, David Holmes <david.holmes at oracle.com
>>>> <mailto:david.holmes at oracle.com>> wrote:
>>>>
>>>> On 19/03/2016 2:58 AM, Brian Gardner wrote:
>>>>> That explains the destructor.  Looking at the initial change set that
>>>>> came out of this bug, we also see the first spot where we set the TLS
>>>>> current thread is set to NULL
>>>>> http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/469835cd5494
>>>>
>>>> Are you referring to:
>>>>
>>>> +  // Thread destructor usually does this.
>>>> +  ThreadLocalStorage::set_thread(NULL);
>>>>
>>>> ? That's only there because the VMThread destructor is never called.
>>>>
>>>>> So I think it?s safe to say that setting TLS current thread to NULL is
>>>>> the correct way to set the state to "destroying thread" and preventing
>>>>> the destructor from looping indefinitely.
>>>>
>>>> I'm not sure exactly what you mean.
>>>>
>>>>>
>>>>> Here is the relevant comment from Andreas:
>>>>>
>>>>> --------------------------------
>>>>>
>>>>> I did find a way to change the JVM to workaround this problem:
>>>>> By creating a destructor for the thread pointer TLS we can restore the
>>>>> value after pthread has set it to NULL.
>>>>> Then when the native code destructor is run the thread pointer is
>>>>> still
>>>>> intact.
>>>>>
>>>>> Restoring a value in a pthread TLS is explicitly supported
>>>>> according to
>>>>> the man page for pthread_key_create, and it will call the
>>>>> destructor for
>>>>> the restored value again.
>>>>> One would have to keep some extra state to make sure the destructor is
>>>>> only called twice, since a pthread implementation is allowed to
>>>>> call the
>>>>> destructor infinite times as long as the value is restored.
>>>>>
>>>>> On my system pthread calls the destructor a maximum of four times, so
>>>>> the attached JVM patch was sufficient as a proof of concept.
>>>>>
>>>>> ????????????????
>>>>
>>>> We implemented the basic patch, we don't do anything to ensure it was
>>>> called at most twice. We expect all well behaving apps to detach
>>>> threads from the JVM before they terminate.
>>>>
>>>> David
>>>> -----
>>>>
>>>>>
>>>>>> On Mar 17, 2016, at 9:02 PM, David Holmes <david.holmes at oracle.com
>>>>>> <mailto:david.holmes at oracle.com>
>>>>>> <mailto:david.holmes at oracle.com>> wrote:
>>>>>>
>>>>>> Thomas writes:
>>>>>>> Hi Brian,
>>>>>>>
>>>>>>>
>>>>>>>> The next patches where less straightforward.  When running java
>>>>>>>> I was
>>>>>>>> getting a ton of messages like:
>>>>>>>> Thread 832744400 has exited with leftover thread-specific data
>>>>>>>> after 4
>>>>>>>> destructor iterations
>>>>>>>> After doing a lot of digging and debugging on Linux, I found the
>>>>>>>> code path
>>>>>>>> for Linux was identical for Freebsd and the cleanup destructor
>>>>>>>> was being
>>>>>>>> executed 4 times just like Freebsd, the difference being that
>>>>>>>> Freebsd would
>>>>>>>> print out this benign warning while Linux would just ignore it.
>>>>>>>> The
>>>>>>>> problem is that all threads that are created and initialize TLS
>>>>>>>> current
>>>>>>>> thread data, must clean them up by explicitly setting the TLS
>>>>>>>> current
>>>>>>>> thread to null.  I?ve come up with two approaches to accomplish
>>>>>>>> this.
>>>>>>>>
>>>>>>>> clean up TLS current thread at end of ::run functions similar to
>>>>>>>> how
>>>>>>>> it's
>>>>>>>> done in openjdk8.
>>>>>>>>
>>>>>>>> http://brian.timestudybuddy.com/webrev/hotspot__clear_thread_current/webrev/
>>>>>>>>
>>>>>>>> clear current thread before exiting java_start to avoid warnings
>>>>>>>> from
>>>>>>>> leftover pthread_setspecific data
>>>>>>>>
>>>>>>>> http://brian.timestudybuddy.com/webrev/hotspot__clear_thread_current_alt/webrev/
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>> I do not think this is a real leak. From what I remember of how
>>>>>>> the glibc
>>>>>>> implements TLS, setting the TLS slot value to NULL would not in
>>>>>>> itself
>>>>>>> delete anything. In VM, this slot keeps the pointer to the current
>>>>>>> Thread*,
>>>>>>> which is correctly deleted at the end of the thread (void
>>>>>>> JavaThread::thread_main_inner()).
>>>>>>>
>>>>>>> Digging further, I found the pthread key destructor
>>>>>>> "restore_thread_pointer(void* p)" in threadLocalStorage_posix.cpp:
>>>>>>>
>>>>>>> // Restore the thread pointer if the destructor is called. This
>>>>>>> is in
>>>>>>> case
>>>>>>> // someone from JNI code sets up a destructor with
>>>>>>> pthread_key_create
>>>>>>> to run
>>>>>>> // detachCurrentThread on thread death. Unless we restore the thread
>>>>>>> pointer we
>>>>>>> // will hang or crash. When detachCurrentThread is called the key
>>>>>>> will be
>>>>>>> set
>>>>>>> // to null and we will not be called again. If
>>>>>>> detachCurrentThread is
>>>>>>> never
>>>>>>> // called we could loop forever depending on the pthread
>>>>>>> implementation.
>>>>>>> extern "C" void restore_thread_pointer(void* p) {
>>>>>>> ThreadLocalStorage::set_thread((Thread*) p);
>>>>>>> }
>>>>>>>
>>>>>>> So, it seems we even reset deliberately the thread pointer to a
>>>>>>> non-NULL
>>>>>>> value. The comment claims that we reset the Thread* value in case
>>>>>>> there is
>>>>>>> another user-provided destructor which runs afterwards and which
>>>>>>> does detachCurrentThread () which would require Thread::current() to
>>>>>>> work.
>>>>>>> But there a details I do not understand:
>>>>>>>
>>>>>>> - At this point, should the Thread* object not already be
>>>>>>> deallocated, so
>>>>>>> this would be a dangling pointer anyway?
>>>>>>>
>>>>>>> - Also, according to Posix, this is unspecified. Doc on
>>>>>>> pthread_setspecific() states: "Calling pthread_setspecific() from a
>>>>>>> thread-specific data destructor routine may result either in lost
>>>>>>> storage
>>>>>>> (after at least PTHREAD_DESTRUCTOR_ITERATIONS attempts at
>>>>>>> destruction) or
>>>>>>> in an infinite loop."
>>>>>>>
>>>>>>> - In jdk8, we did reset the slot value to NULL before Thread exit.
>>>>>>> So, in
>>>>>>> this case detachCurrentThread() from a pthread_key destructor
>>>>>>> should not
>>>>>>> have worked at all.
>>>>>>>
>>>>>>> Could someone from Oracle maybe shed light on this?
>>>>>>
>>>>>> Please see the following discussion and bug report:
>>>>>>
>>>>>> http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2014-February/010759.html
>>>>>>
>>>>>>
>>>>>> Note I don't follow this list so please include me directly in any
>>>>>> follow-ups if needed.
>>>>>>
>>>>>> Thanks,
>>>>>> David
>>>
>>>
>>

From hammad_a17 at yahoo.com  Tue Mar 22 20:28:35 2016
From: hammad_a17 at yahoo.com (AMAL.Adnan HAMMAD)
Date: Wed, 23 Mar 2016 00:28:35 +0400
Subject: sft
Message-ID: <52ECFBDF-EEF9-42C0-9117-871C9DB2DDC7@yahoo.com>

FIN#1087168920

Amal Adnan Hammad
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/bsd-port-dev/attachments/20160323/4874bd4f/attachment.html>

From glewis at eyesbeyond.com  Sun Mar 27 06:52:44 2016
From: glewis at eyesbeyond.com (glewis at eyesbeyond.com)
Date: Sun, 27 Mar 2016 06:52:44 +0000
Subject: hg: bsd-port/jdk8/jaxws: 4 new changesets
Message-ID: <201603270652.u2R6qies029649@aojmv0008.oracle.com>

Changeset: a2f8a45d70b2
Author:    asaha
Date:      2016-01-29 14:14 -0800
URL:       http://hg.openjdk.java.net/bsd-port/jdk8/jaxws/rev/a2f8a45d70b2

Added tag jdk8u74-b02 for changeset 6cfef18571fd

! .hgtags

Changeset: dd34713088c2
Author:    asaha
Date:      2016-03-15 23:56 -0700
URL:       http://hg.openjdk.java.net/bsd-port/jdk8/jaxws/rev/dd34713088c2

Added tag jdk8u77-b00 for changeset a2f8a45d70b2

! .hgtags

Changeset: 7c319d6e0d4c
Author:    asaha
Date:      2016-03-16 00:09 -0700
URL:       http://hg.openjdk.java.net/bsd-port/jdk8/jaxws/rev/7c319d6e0d4c

Added tag jdk8u77-b01 for changeset dd34713088c2

! .hgtags

Changeset: c6f67bea4466
Author:    asaha
Date:      2016-03-18 22:30 -0700
URL:       http://hg.openjdk.java.net/bsd-port/jdk8/jaxws/rev/c6f67bea4466

Added tag jdk8u77-b02 for changeset 7c319d6e0d4c

! .hgtags


From glewis at eyesbeyond.com  Sun Mar 27 06:52:42 2016
From: glewis at eyesbeyond.com (glewis at eyesbeyond.com)
Date: Sun, 27 Mar 2016 06:52:42 +0000
Subject: hg: bsd-port/jdk8/langtools: 5 new changesets
Message-ID: <201603270652.u2R6qgPj029640@aojmv0008.oracle.com>

Changeset: ae2485fab956
Author:    asaha
Date:      2016-01-29 14:16 -0800
URL:       http://hg.openjdk.java.net/bsd-port/jdk8/langtools/rev/ae2485fab956

Added tag jdk8u74-b02 for changeset 55934388691b

! .hgtags

Changeset: 37a348477fe8
Author:    asaha
Date:      2016-03-16 00:00 -0700
URL:       http://hg.openjdk.java.net/bsd-port/jdk8/langtools/rev/37a348477fe8

Added tag jdk8u77-b00 for changeset ae2485fab956

! .hgtags

Changeset: 47efac0d6798
Author:    asaha
Date:      2016-03-16 00:10 -0700
URL:       http://hg.openjdk.java.net/bsd-port/jdk8/langtools/rev/47efac0d6798

Added tag jdk8u77-b01 for changeset 37a348477fe8

! .hgtags

Changeset: 094308b2ca1c
Author:    asaha
Date:      2016-03-18 22:31 -0700
URL:       http://hg.openjdk.java.net/bsd-port/jdk8/langtools/rev/094308b2ca1c

Added tag jdk8u77-b02 for changeset 47efac0d6798

! .hgtags

Changeset: db5d96456ace
Author:    Greg Lewis <glewis at eyesbeyond.com>
Date:      2016-03-26 16:34 -0700
URL:       http://hg.openjdk.java.net/bsd-port/jdk8/langtools/rev/db5d96456ace

Merge from main OpenJDK repository



From glewis at eyesbeyond.com  Sun Mar 27 06:52:44 2016
From: glewis at eyesbeyond.com (glewis at eyesbeyond.com)
Date: Sun, 27 Mar 2016 06:52:44 +0000
Subject: hg: bsd-port/jdk8/jdk: 6 new changesets
Message-ID: <201603270652.u2R6qjIg029650@aojmv0008.oracle.com>

Changeset: 02e120964805
Author:    asaha
Date:      2016-01-29 14:14 -0800
URL:       http://hg.openjdk.java.net/bsd-port/jdk8/jdk/rev/02e120964805

Added tag jdk8u74-b02 for changeset 32c49f4a1659

! .hgtags

Changeset: f08584a0fde9
Author:    asaha
Date:      2016-03-21 13:31 -0700
URL:       http://hg.openjdk.java.net/bsd-port/jdk8/jdk/rev/f08584a0fde9

Added tag jdk8u77-b00 for changeset 02e120964805

! .hgtags

Changeset: 1a3e81c05703
Author:    asaha
Date:      2016-03-21 13:31 -0700
URL:       http://hg.openjdk.java.net/bsd-port/jdk8/jdk/rev/1a3e81c05703

Added tag jdk8u77-b01 for changeset f08584a0fde9

! .hgtags

Changeset: 6d4565e23839
Author:    asaha
Date:      2016-03-21 13:34 -0700
URL:       http://hg.openjdk.java.net/bsd-port/jdk8/jdk/rev/6d4565e23839

Added tag jdk8u77-b02 for changeset 1a3e81c05703

! .hgtags

Changeset: c44179bce874
Author:    poonam
Date:      2016-03-21 13:37 -0700
URL:       http://hg.openjdk.java.net/bsd-port/jdk8/jdk/rev/c44179bce874

8152335: Improve MethodHandle consistency
Reviewed-by: vlivanov, acorn, jrose

! src/share/classes/java/lang/ClassLoader.java
! src/share/classes/java/lang/invoke/MemberName.java
! src/share/classes/java/lang/invoke/MethodHandleNatives.java
! src/share/classes/sun/invoke/util/VerifyAccess.java

Changeset: fa6589d31b09
Author:    Greg Lewis <glewis at eyesbeyond.com>
Date:      2016-03-26 16:34 -0700
URL:       http://hg.openjdk.java.net/bsd-port/jdk8/jdk/rev/fa6589d31b09

Merge from main OpenJDK repository

- src/macosx/classes/java/net/DefaultInterface.java
- src/macosx/classes/sun/nio/ch/DefaultSelectorProvider.java
- src/macosx/classes/sun/nio/ch/KQueueArrayWrapper.java
- src/macosx/classes/sun/nio/ch/KQueueSelectorImpl.java
- src/macosx/classes/sun/nio/ch/KQueueSelectorProvider.java
- src/macosx/native/sun/nio/ch/KQueueArrayWrapper.c


From glewis at eyesbeyond.com  Sun Mar 27 06:52:40 2016
From: glewis at eyesbeyond.com (glewis at eyesbeyond.com)
Date: Sun, 27 Mar 2016 06:52:40 +0000
Subject: hg: bsd-port/jdk8/jaxp: 4 new changesets
Message-ID: <201603270652.u2R6qe9I029545@aojmv0008.oracle.com>

Changeset: 8cc52edbb741
Author:    asaha
Date:      2016-01-29 14:14 -0800
URL:       http://hg.openjdk.java.net/bsd-port/jdk8/jaxp/rev/8cc52edbb741

Added tag jdk8u74-b02 for changeset b3325c052662

! .hgtags

Changeset: 8f0ed89698a2
Author:    asaha
Date:      2016-03-15 23:55 -0700
URL:       http://hg.openjdk.java.net/bsd-port/jdk8/jaxp/rev/8f0ed89698a2

Added tag jdk8u77-b00 for changeset 8cc52edbb741

! .hgtags

Changeset: 27f1130320a5
Author:    asaha
Date:      2016-03-16 00:08 -0700
URL:       http://hg.openjdk.java.net/bsd-port/jdk8/jaxp/rev/27f1130320a5

Added tag jdk8u77-b01 for changeset 8f0ed89698a2

! .hgtags

Changeset: 1c71899e8566
Author:    asaha
Date:      2016-03-18 22:30 -0700
URL:       http://hg.openjdk.java.net/bsd-port/jdk8/jaxp/rev/1c71899e8566

Added tag jdk8u77-b02 for changeset 27f1130320a5

! .hgtags


From glewis at eyesbeyond.com  Sun Mar 27 06:52:45 2016
From: glewis at eyesbeyond.com (glewis at eyesbeyond.com)
Date: Sun, 27 Mar 2016 06:52:45 +0000
Subject: hg: bsd-port/jdk8/nashorn: 5 new changesets
Message-ID: <201603270652.u2R6qjOw029651@aojmv0008.oracle.com>

Changeset: 7bce03d47545
Author:    asaha
Date:      2016-01-29 14:16 -0800
URL:       http://hg.openjdk.java.net/bsd-port/jdk8/nashorn/rev/7bce03d47545

Added tag jdk8u74-b02 for changeset 3107cf87696f

! .hgtags

Changeset: 678b645aa10a
Author:    asaha
Date:      2016-03-16 00:00 -0700
URL:       http://hg.openjdk.java.net/bsd-port/jdk8/nashorn/rev/678b645aa10a

Added tag jdk8u77-b00 for changeset 7bce03d47545

! .hgtags

Changeset: 09abd795d1d1
Author:    asaha
Date:      2016-03-16 00:10 -0700
URL:       http://hg.openjdk.java.net/bsd-port/jdk8/nashorn/rev/09abd795d1d1

Added tag jdk8u77-b01 for changeset 678b645aa10a

! .hgtags

Changeset: b6ee21a35619
Author:    asaha
Date:      2016-03-18 22:31 -0700
URL:       http://hg.openjdk.java.net/bsd-port/jdk8/nashorn/rev/b6ee21a35619

Added tag jdk8u77-b02 for changeset 09abd795d1d1

! .hgtags

Changeset: 1a1fa81886e1
Author:    Greg Lewis <glewis at eyesbeyond.com>
Date:      2016-03-26 16:34 -0700
URL:       http://hg.openjdk.java.net/bsd-port/jdk8/nashorn/rev/1a1fa81886e1

Merge from main OpenJDK repository



From glewis at eyesbeyond.com  Sun Mar 27 06:52:41 2016
From: glewis at eyesbeyond.com (glewis at eyesbeyond.com)
Date: Sun, 27 Mar 2016 06:52:41 +0000
Subject: hg: bsd-port/jdk8/corba: 4 new changesets
Message-ID: <201603270652.u2R6qf2x029600@aojmv0008.oracle.com>

Changeset: 7b719c1dec62
Author:    asaha
Date:      2016-01-29 14:12 -0800
URL:       http://hg.openjdk.java.net/bsd-port/jdk8/corba/rev/7b719c1dec62

Added tag jdk8u74-b02 for changeset 5eb60567655e

! .hgtags

Changeset: cafc1648f432
Author:    asaha
Date:      2016-03-15 23:53 -0700
URL:       http://hg.openjdk.java.net/bsd-port/jdk8/corba/rev/cafc1648f432

Added tag jdk8u77-b00 for changeset 7b719c1dec62

! .hgtags

Changeset: 0f0077ee5e53
Author:    asaha
Date:      2016-03-16 00:07 -0700
URL:       http://hg.openjdk.java.net/bsd-port/jdk8/corba/rev/0f0077ee5e53

Added tag jdk8u77-b01 for changeset cafc1648f432

! .hgtags

Changeset: e8dc6eb11c76
Author:    asaha
Date:      2016-03-18 22:29 -0700
URL:       http://hg.openjdk.java.net/bsd-port/jdk8/corba/rev/e8dc6eb11c76

Added tag jdk8u77-b02 for changeset 0f0077ee5e53

! .hgtags


From glewis at eyesbeyond.com  Sun Mar 27 06:52:43 2016
From: glewis at eyesbeyond.com (glewis at eyesbeyond.com)
Date: Sun, 27 Mar 2016 06:52:43 +0000
Subject: hg: bsd-port/jdk8/hotspot: 5 new changesets
Message-ID: <201603270652.u2R6qh31029647@aojmv0008.oracle.com>

Changeset: 1b6d4fd2730e
Author:    asaha
Date:      2016-01-29 14:13 -0800
URL:       http://hg.openjdk.java.net/bsd-port/jdk8/hotspot/rev/1b6d4fd2730e

Added tag jdk8u74-b02 for changeset ca9cae9aa9e9

! .hgtags

Changeset: ddd297e340b1
Author:    asaha
Date:      2016-03-15 23:54 -0700
URL:       http://hg.openjdk.java.net/bsd-port/jdk8/hotspot/rev/ddd297e340b1

Added tag jdk8u77-b00 for changeset 1b6d4fd2730e

! .hgtags

Changeset: 1b4072e4bb3a
Author:    asaha
Date:      2016-03-16 00:07 -0700
URL:       http://hg.openjdk.java.net/bsd-port/jdk8/hotspot/rev/1b4072e4bb3a

Added tag jdk8u77-b01 for changeset ddd297e340b1

! .hgtags

Changeset: 223b64a19e94
Author:    asaha
Date:      2016-03-18 22:29 -0700
URL:       http://hg.openjdk.java.net/bsd-port/jdk8/hotspot/rev/223b64a19e94

Added tag jdk8u77-b02 for changeset 1b4072e4bb3a

! .hgtags

Changeset: c8129460da17
Author:    Greg Lewis <glewis at eyesbeyond.com>
Date:      2016-03-26 16:34 -0700
URL:       http://hg.openjdk.java.net/bsd-port/jdk8/hotspot/rev/c8129460da17

Merge from main OpenJDK repository



From glewis at eyesbeyond.com  Sun Mar 27 06:52:40 2016
From: glewis at eyesbeyond.com (glewis at eyesbeyond.com)
Date: Sun, 27 Mar 2016 06:52:40 +0000
Subject: hg: bsd-port/jdk8: 5 new changesets
Message-ID: <201603270652.u2R6qe05029563@aojmv0008.oracle.com>

Changeset: 417ff12d11d6
Author:    asaha
Date:      2016-01-29 14:12 -0800
URL:       http://hg.openjdk.java.net/bsd-port/jdk8/rev/417ff12d11d6

Added tag jdk8u74-b02 for changeset bee679b986f5

! .hgtags

Changeset: 6683e1d7422d
Author:    asaha
Date:      2016-03-15 23:53 -0700
URL:       http://hg.openjdk.java.net/bsd-port/jdk8/rev/6683e1d7422d

Added tag jdk8u77-b00 for changeset 417ff12d11d6

! .hgtags

Changeset: 7dd1be8bd46c
Author:    asaha
Date:      2016-03-16 00:07 -0700
URL:       http://hg.openjdk.java.net/bsd-port/jdk8/rev/7dd1be8bd46c

Added tag jdk8u77-b01 for changeset 6683e1d7422d

! .hgtags

Changeset: 3fbef9f4cddf
Author:    asaha
Date:      2016-03-18 22:29 -0700
URL:       http://hg.openjdk.java.net/bsd-port/jdk8/rev/3fbef9f4cddf

Added tag jdk8u77-b02 for changeset 7dd1be8bd46c

! .hgtags

Changeset: 0f41e42a586e
Author:    Greg Lewis <glewis at eyesbeyond.com>
Date:      2016-03-26 16:34 -0700
URL:       http://hg.openjdk.java.net/bsd-port/jdk8/rev/0f41e42a586e

Merge from main OpenJDK repository