Andrew Haley wrote: > Jeroen Frijters wrote: >> Andrew Haley wrote: >>> It's not just static compilation: if you look at >>> VMThread.currentThread() you'll probably see something like >>> >>> extern DWORD _Jv_ThreadKey; >>> return (java::lang::Thread *) TlsGetValue(_Jv_ThreadKey); >>> >>> or >>> >>> extern pthread_key_t _Jv_ThreadKey; >>> return (java::lang::Thread *) pthread_getspecific (_Jv_ThreadKey); >>> >>> You see my point? >> It's probably me, but taking PTHREAD_KEYS_MAX, non-conservative GC and >> thread local inheritance into account makes me think that the current >> approach is superior. > > Why? If you're going to call pthread_getspecific() to get the current > thread, you might as well call it to get the thread-local variable. > That remains true regardless of GC, TL inheritance, or anything else.
Thinking about it some more, I suppose there may be one interesting case where a Java implementation has some kind of super-fast optimization of VMThread.currentThread() in the VM itself but very slow JNI. In this case the all-Java implementation might be faster than using OS-supplied thread locals. Andrew.
