In order to tease out where the performance differences were coming from, I implemented a map specialized for thread locals (ThreadLocalMap.java) and found that the performance is essentially the same as the version Ian posted earlier that stores ThreadLocal data in a per-thread direct indexed array.
Steve ran the numbers for first and third iteration performance (-1 and -3). http://cs.anu.edu.au/people/Steve.Blackburn/jikesrvm/vole-2007-08-22-Wed -213259-1.txt http://cs.anu.edu.au/people/Steve.Blackburn/jikesrvm/vole-2007-08-22-Wed -213259-3.txt All numbers are from JikesRVM and listed from left to right are the original (WeakIdentityHashMap) the array version suggested by Ian, and the ThreadLocalMap version. The implementation is essentially a map of weak references to values that are lazily cleaned up as the map is manipulated. I think this is a good balance of performance and design, but I am open to suggestions. To allow other VMs to benefit from this I have made all these changes within classpath (patch attached). The job still remains to improve the WeakIdentityHashMap so it does not perform allocation as it searches the buckets in the fast case for a simple get(), but I believe that optimizing the ThreadLocal case is worthwhile regardless as in some benchmarks they are performance critical. Thanks & Regards, Daniel Frampton. > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:jikesrvm- > [EMAIL PROTECTED] On Behalf Of Jeroen Frijters > Sent: Wednesday, 22 August 2007 7:28 PM > To: Ian Rogers > Cc: [EMAIL PROTECTED]; members; classpath- > [EMAIL PROTECTED] > Subject: Re: [Jikesrvm-core] [cp-patches] Changes to ThreadLocal > > Ian Rogers wrote: > > Thanks Jeroen, it's clear now. The problem with a phantom reference > is > > that when we collect the thread local we should also really make > > collectable all of the values set to thread locals. A phantom > reference > > won't do this and so introduces a memory leak until something can run > > over the queue of phantom references freeing all the allocated thread > > local slots. As you say, we can use phantom references, wouldn't > > another way be to implement say our own system weak reference, with a > > guarantee there are no references and weak references to the object? > > Having a thread that polls a normally empty queue seems undesirable > > both for this and Classpath bug 29499. > > The thread doesn't actually need to poll (ReferenceQueue.remove() is a > blocking operation), but burning a thread on this does suck. OTOH, > there are a lot of other areas in the class lib that create background > threads. > > I think the best thing would be to have a VM interface that handles the > clean up and provide a default implementation that uses > PhantomReference and allows VMs to provide a more efficient clean up > mechanism. Ideally the mechanism would be flexible enough to also be > used for #29499. > > OpenJDK has the sun.misc.Cleaner class for this. It extends > PhantomReference, but it is treated specially by the finalizer thread, > so that these aren't actually enqueued but processed by the finalizer > thread itself. > > Regards, > Jeroen > > > ----------------------------------------------------------------------- > -- > This SF.net email is sponsored by: Splunk Inc. > Still grepping through log files to find problems? Stop. > Now Search log events and configuration files using AJAX and a browser. > Download your FREE copy of Splunk now >> http://get.splunk.com/ > _______________________________________________ > Jikesrvm-core mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/jikesrvm-core
classpath95-ThreadLocalMap.patch
Description: classpath95-ThreadLocalMap.patch
