Hi,
I'm a bit hesitant to step in the discussion among such knowledgeable
gentlemen, so forgive me if the suggestion is too naive :-)
The class loader doesn't unload individual classes because they can
hold static members or have static initializers, and unloading the
class may break the program semantics, right? However the classes
generated for functions do not have any members, and certainly no
static ones, so that's not an issue. What if for every classloader in
the system we'd create one dedicated child classloader for all these
function objects, which would not hold hard references to the classes
it loads making them eligible for GC. Then some sort of factory can
load "function objects" using that special loader.
This would only double the current number of classloaders in the
system, which isn't too bad, I think. There's still plenty of issues,
I'm sure... Dunno, just an idea.
Yardena.
On Jan 17, 3:19 pm, Attila Szegedi <[EMAIL PROTECTED]> wrote:
> 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: jvm-languages@googlegroups.com [mailto:jvm-
> >> [EMAIL PROTECTED] On Behalf Of Charles Oliver Nutter
> >> Sent: Tuesday, January 15, 2008 12:57 AM
> >> To: jvm-languages@googlegroups.com
> >> 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 jvm-languages@googlegroups.com
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
-~----------~----~----~----~------~----~------~--~---
