sebb schrieb:
On 16/09/2008, Simon Kitching <[EMAIL PROTECTED]> wrote:
One other concern is regarding garbage collection. From a brief look at the
code, this thread-local registry object contains a set of Integer hashcodes.
With this change, the set will now contain real hard references to objects,
preventing them from being garbage-collected while they are in the set. Does
this matter?
The entries are only retained in the registry during the hashcode
calculation - if any were left behind they could mess up subsequent
calls in the same thread.
As far as I can see, the code always removes any items that are added,
but it would be worth double-checking that.
I did suspect that the objects are removed from the registry before
normal return. So then the IDKey approach should be fine.
But it would seem to me to be safer to have a call to registry.remove()
to ensure that the threadlocal object is completely cleared, rather than
just relying on the code to correctly balance adds/removes on the
HashSet. Or a call to getRegistry().clear(). Or at least a comment on
the registry stating that it is always empty on return from the
reflectionHashCode method etc.
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.
Or is it to "tunnel" the registry set between cooperating classes? If
the latter, then registry.remove() seems a good idea when it is no
longer used, to avoid leaking an object per thread.
Sorry for the vague comments; I don't have time to really get to grips
with the code ATM..
Regards,
Simon
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
