(L) Prelim RFR: 8132510: Replace ThreadLocalStorage with compiler/language-based thread-local variables

[Thomas Stüfe]

On Wed, Nov 11, 2015 at 11:56 AM, Andrew Haley <aph at redhat.com> wrote:

> On 09/11/15 23:55, David Holmes wrote:
> > On 9/11/2015 8:54 AM, David Holmes wrote:
> >
> > Just to keep my thinking straight on this, the problem only exists for
> > threads that existed before the JVM was loaded. All threads allocated
> > after that will have space for all the TLS variables allocated directly.
> > So the problem scenario is:
> >
> > - external process with existing threads loads the JVM
> > - existing thread is executing critical library function eg malloc, when
> > it takes a process-directed signal.
> > - JVM signal handler runs and accesses _thr_current which triggers
> > dynamic TLS allocation
>
> Why not simply use pthread_* thread-local storage, but only in the
> signal handler?  That would avoid the (fairly unlikely) race
> condition, at very little cost.  Sure, we'd have to use
> pthread_setspecific() when attaching a thread, but that's no big deal.
>
>
This could work. So, initialize both the pthread TLS slot and the __thread
variable on thread creation. We could name them Thread::current and
Thread::current_safe or similar.

However, we still do not know how big the performance advantage is in using
__thread over pthread_getspecific(). May not even worth all the trouble of
using __thread.

Thomas


> Andrew.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/porters-dev/attachments/20151111/2de46cb3/attachment.html>