Re: [cp-patches] RFC: ClassLoader associative cache

[Archie Cobbs]

Jeroen Frijters wrote:
 There are several places in our codebase were we need/want to cache
 stuff that is associated with a class or class loader. Currently these
 places retain a strong reference to the class loader, which is not
 correct, because the class loader should be garbage collectable.
 
 I cooked up proposal for an API to use for this and implemented it in
 the three places I could think of off the top my head (serialization,
 proxy and resource bundle).
 
 This is just a first stab, so no documentation and no change log entry
 yet. Please comment on the idea and/or the API.

Dumb question.. why wouldn't it work to just use a WeakHashMap instead
of a HashMap in all those places?

-Archie

__
Archie Cobbs  *CTO, Awarix*  http://www.awarix.com

RE: [cp-patches] RFC: ClassLoader associative cache

[Jeroen Frijters]

Jeroen Frijters wrote:
 Archie Cobbs wrote:
  Dumb question.. why wouldn't it work to just use a 
  WeakHashMap instead of a HashMap in all those places?
 
 Not a dumb question at all. That *would* work. The problem 
 is that (at least on some runtimes) WeakHashMap is much more
 expensive than this approach.

Actually, it would not work in all cases. For serialization it would
work, because there the key is a Class instance, but for both Proxy and
ResourceBundle, the key is more complex, so it wouldn't work to directly
use a WeakHashMap (you'd have to add a layer of indirection, effectively
keeping a separate cache per class loader and in that case this approach
is arguably better).

There may be other reasons, Roman also didn't like to use a WeakHashMap,
but I didn't ask why.

Using a WeakHashMap would also make it a little harder to implement the
ResourceBundle LRU policy, but that was not the motivation for this
approach.

Regards,
Jeroen