Thomas,
You wrote:
"If Class.forName could find the class, then surely the class and loader
are still reachable and not collectable?"
I would have thought so. But we haven't found current
implementations to behave according to this reasoning.
-----Original Message-----
From: owner-javamemorymodel@cs.umd.edu
[mailto:owner-javamemorymodel@cs.umd.edu]On Behalf Of Thomas Hawtin
Sent: Friday, 21 May 2004 1:50 p.m.
To: javamemorymodel@cs.umd.edu
Subject: Re: JavaMemoryModel: When can a classloader be unloaded
Evan Ireland wrote:
>
> A piece of code which calls MyCache.get() in a loop, using the reflection
> API (Class.forName(...).getMethod(...).invoke(...)) will break if class
> garbage collection is used, as any data that is put in the cache after
> one call might disappear by the next call.
If Class.forName could find the class, then surely the class and loader
are still reachable and not collectable? If however, you used a weak
reference to the class, method or class loader then the class and loader
may be reclaimed, perhaps even before the method returns. But presumably
you wouldn't be using a weak reference if you didn't want that sort of
thing to happen.
> Frankly, I think that class GC is a broken concept. We disable it
> in our application server because it breaks user-defined caches.
As classes and loaders effectively have strong references to each other,
it seem eminently sensible to me. Why can't compiled code be cached
like everything else? Why keep dead code over until reboot?
Tom Hawtin
-------------------------------
JavaMemoryModel mailing list - http://www.cs.umd.edu/~pugh/java/memoryModel
-------------------------------
JavaMemoryModel mailing list - http://www.cs.umd.edu/~pugh/java/memoryModel
This archive was generated by hypermail 2b29 : Thu Oct 13 2005 - 07:01:07 EDT