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

Andrew Haley aph at redhat.com
Wed Nov 11 10:56:43 UTC 2015


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.

Andrew.


More information about the porters-dev mailing list