Ian Rogers wrote:
Andrew Haley wrote:
Andrew John Hughes wrote:
Daniel's copyright assignment is finally through, so
I'm committing this patch which optimises the use of
ThreadLocals by replacing the use of the generic java.util.WeakHashMap
with a ThreadLocal-specific implementation.
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
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;
Andrew Haley wrote:
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.
PTHREAD_KEYS_MAX is very low on some OSes compared with the needs
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
Jeroen Frijters wrote:
Andrew Haley wrote:
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.
PTHREAD_KEYS_MAX is very low on some
