On 2008.01.17., at 10:26, Ted Neward wrote:
> All of the scenarios you describe below suggest, then, that so long
> as a
> strong reference is held to the class, the class is not eligible for
> unloading. That means, of course, that once all strong references
> have been
> dropped, the class is now eligible for unloading.
Right, but the fact that the ClassLoader holds a strong reference to
all Class objects it loaded means that a class is not eligible for GC
until all classes loaded through the same class loader themselves
become eligible.
Functions being first-class objects in most of languages we discuss
here, their usual implementation is to generate an on-the-fly class,
i.e. "class 0a9cee3478 implements Function { ... }" and instantiate
exactly one instance of it to pass around as said first-class object.
If we want to have our functions to be garbage collectibe with a
single function granularity, then the class for each one of them needs
to be loaded in its own class loader that only loads that class and
nothing else . And that's what feels unnecessarily convoluted (having
one classloader per class) and raises the requirement for some
"lightweight method objects".
> [...]
>
> Dropping the Vector out of the ClassLoader base class I think breaks
> a bunch
> of other stuff, but I don't remember why. (It's been a while since I
> tried
> to track that guy down.) I vaguely recall it being added in 1.2 for a
> particular reason. IIRC, there's another collection of hard references
> buried inside the native code, from what I understand, called the
> Loaded
> Class Cache (LCC), and those references would likely keep the class
> alive
> even if you could yank it out of that Vector.
I'm not 100% sure about the limitations here myself, or whether they
could be partially lifted. I certainly hope they could :-) It's
embarrassing, but I think I once knew the reason, but can't seem to
remember it anymore.
On the other hand, the invariant that classes unload in bulk (when
their loader becomes unreachable) is maybe taken advantage of in the
JVM guts somehow -- i.e. JIT call site optimization/deoptimization can
be tied to a ClassLoader going away instead of checked on a per class
basis, and similars. That might cause some further resistance for
relaxing the rules from people who maintain JVMs.
> I also believe that Class needs to hard reference the ClassLoader in
> order
> to support the getResource() behavior on Class, which means we can't
> get rid
> of those strong references, either.
Nope, but that's not being debated :-)
> I dunno who at Sun owns the ClassLoader facilities in the JVM these
> days--I
> got my LCC info from Peter Kessler (sp?) at Sun, IIRC. He/she would
> be the
> right one to tell us why that Vector exists, or if what you want is
> even
> remotely feasible under the current JVM architecture.
That'd indeed be great.
Attila.
> Anybody know who that
> might be? (I'd love to know, just so I can ask some related but off-
> topic
> questions, too. ;-) )
>
>
> Ted Neward
> Java, .NET, XML Services
> Consulting, Teaching, Speaking, Writing
> http://www.tedneward.com
>
>
>> -----Original Message-----
>> From: [email protected] [mailto:jvm-
>> [EMAIL PROTECTED] On Behalf Of Charles Oliver Nutter
>> Sent: Tuesday, January 15, 2008 12:57 AM
>> To: [email protected]
>> Subject: [jvm-l] Re: Ability to force class unloading in JDK 6 Update
>> 4?
>>
>>
>> Ted Neward wrote:
>>> Hate to say it, Kresten, but I don't think you'll ever see this--the
>>> semantics of unloading classes, except by GC, would need to be
>>> worked
>> out
>>> and codified someplace before this could happen.
>>
>> I think the thing Kresten is looking for is an ability to unload
>> classes
>> (or make them eligible for GC) when they are known to be unused. Or
>> if
>> he's not, that's what I want.
>>
>>> Assume for the moment that we go with a simpler implementation,
>>> System.classGC() that takes a Class object and unloads it. (Ignore
>> the
>>> complications of ClassLoaders for now.) Suppose...
>>> (*) ... there is an instance of that Class still reachable in the
>> system?
>>> What should happen?
>>
>> It's a hard reference; there's nothing new here. An object references
>> its class.
>>
>>> (*) ... this is an abstract class that is inherited by other classes
>> in the
>>> system (which may or may not have instances still reachable)?
>>
>> A child class has a hard reference to a parent class. No problem.
>>
>>> (*) ... you're in the middle of a static method execution call on
>> that class
>>> on another Thread?
>>
>> Then there's a hard reference to that class from that thread or from
>> frame executing it.
>>
>>> (*) ... another thread is *about* (say, five seconds from now) to
>> make a
>>> static method execution call on that class?
>>
>> Can't predict the future; but if the caller already has a reference
>> to
>> the class it wouldn't be able to go away.
>>
>> In general, if all reference to a class go away, there should be a
>> way
>> to make it eligible for immediate GC.
>>
>> The larger issues, as I understand them, relate to static
>> initializers.
>> In order to guarantee the static initializers don't fire again
>> under a
>> given classloader, there must be guarantees about classes staying
>> alive.
>> If they could GC when there are no more references to them, their
>> static
>> initializers could fire again.
>>
>> However, there's a lot of uses for classes that don't require such
>> guarantees, such as generating anonymous classes to hold code
>> compiled
>> at runtime. I don't care if the classes I compile in JRuby's JIT get
>> unloaded or reloaded, because I'll manage my own references to them.
>> But
>> because of the Vector in ClassLoader...they tend to stick around too
>> long without ClassLoader tricks.
>>
>> - Charlie
>>
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "JVM
Languages" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/jvm-languages?hl=en
-~----------~----~----~----~------~----~------~--~---
