(L) Prelim RFR: 8132510: Replace ThreadLocalStorage with compiler/language-based thread-local variables
thomas.stuefe at gmail.com
Wed Nov 11 15:03:44 UTC 2015
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
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the porters-dev