On Tue, Jan 13, 2009 at 12:08 PM, Ville Voutilainen
> On Tue, Jan 13, 2009 at 12:41 PM, Philip Hudson <phil.hudson@...> wrote:
>> On 13 Jan, 2009, at 10:28 am, Erik Huelsmann wrote:
>>> 2) Avoid the call to LispThread.currentThread(): it's cost is 10 times
>>> higher than calling Thread.currentThread(). However, we can't use the
>>> latter because it doesn't offer opportunities to store "user data".
>> Might Java ThreadLocal objects give us the required per-thread "user
>> data" storage, and improve encapsulation?
> In theory yes. Then it might become a balance issue, where performance is lost
> in storing the thread-specific data when it's not needed. At the
> moment various bits of code retrieve current thread when they need it.
> Also, various bits (eg. Closure.java)
> attempt to retrieve the current thread only once and pass it around to
> functions that need it. This could result in large, sweeping changes, so it would be
> nice to have some sort of abstraction first that could hide whether
> Lisp.CurrentThread is used or whether ThreadLocal would be used.
You're aware that I changed the implementation of
LispThread.currentThread() last weekend from using a synchronised
WeakHashMap to a ThreadLocal storage? Regardless, the speed difference
(in my measurements) is still a factor 10 with respect to
Thread.currentThread() [in the uncontended case]. Ofcourse, it can be
no speedier than that, because it uses it itsef to key the
thread-local key on. It would be really nice to have some per thread
storage within the thread-object, but it seems that's not possible
with the current Thread implementation.