commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Simon Kitching <>
Subject Re: [LANG] - suggestions for new Identity Hash code classes
Date Tue, 16 Sep 2008 14:42:28 GMT
sebb schrieb:
> On 16/09/2008, Jörg Schaible <> wrote:
>> sebb wrote:
>>  > On 16/09/2008, Simon Kitching <> wrote:
>> [snip]
>>>>  It's not quite clear to me why a threadlocal is being used here. I'm
>>  >> guessing it is for performance to avoid recreating the HashSet
>>  >> object.
>>  >
>>  > I don't know for sure, but that is probably the case.
>>  >
>>  >> Or is
>>  >> it to "tunnel" the registry set between cooperating classes?
>>  >
>>  > Not at present, although the registy access methods are
>>  > package protected.
>>  >
>>  > That may be a mistake...
>> My guess: It's used in case of a circular object graph ...
> Yes, they are used in the enclosing class for just that purpose.
> But as far as I can see there is no need for the methods to be
> anything other than private - and the contents of the HashMap only
> contain anything during the calculation of the hashcode, so it's not
> obvious how the methods could be called anyway.
> I meant it was probably a mistake for the methods to be package protected.
In that case, I wonder why it bothers to use a thread-local at all, 
rather than just passing the registry object around as a parameter...

Is the performance benefit of avoiding creation of a HashSet object 
really measurable given that this class is doing significant amounts of 

Because this class never calls ThreadLocal.remove(), the created HashSet 
object will remain attached to every thread that ever was active when a 
HashCodeBuilder call was made. That's not *too* bad, ie it seems to me 
that it would be acceptable as long as there was a corresponding benefit 
somewhere. But I can't see the benefit ATM..

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message