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 OSes compared with the needs of some > Java apps.
OK, that makes sense. On such OSes you might as well do it in Java. (Sigh. I just did a web search to find out which OSes had such small PTHREAD_KEYS_MAX, and, to no surprise, found Darwin.) > Non-conservative GC means that an extra indirection layer is needed, > you might as well add another one and hang everything off the Thread object. No, it's not like that. For the sake of the GC you have to maintain some sort of table of the values in the Java heap. However, if you have a very fast OS-provided mechanism for thread locals -- and on GNU/Linux you do -- you might as well use that mechanism as a fast way to bypass the table. >>> Not to mention the VMs that already have Thread.currentThread() >>> specific optimizations. >> Sure, but they might as well optimize ThreadLocals while they're at it. > > Maybe, but for IKVM that wouldn't have been an option due to the peculiarities > of the underlying platform OK. It might be that the most useful optimization for some VMs would be to use a real thread-local variable (rather than POSIX TLS) for currentThread(). We don't do that in libgcj because when that part of the library was written real thread-local variables didn't exist. Andrew.
