Re: [Jamvm-general] Class.forName creates hard reference to classloader?

[Robert L. <rob...@gm...>]

Hi Tom,

Yes that will happen, because JamVM doesn't currently support garbage
collection and unloading of classes.

All classes have an internal reference to their defining class loader
and a list of initiating class loaders.  Therefore, as far as JamVM is
concerned there's still a strong reference to the class-loader (from
foo) and it isn't collected.

Strangely enough, I began thinking about class-unloading yesterday as
the next thing to do!  It's not a major change to the GC (unlike
Soft/Weak/References).  If you're interested I expect to have an
initial version in CVS in the next few days.

Rob.

On 12/1/05, Tom Dunstan <to...@gm...> wrote:
> Hi folks!
>
> While hacking on classpath's java.lang.reference.Proxy to make it
> support throwaway classloaders I hit an odd problem, and I think that
> it's happening inside jamvm, so I'm reporting it here first. :)
>
> It seems that if I pass a classloader to Class.forName("foo", false,
> someClassLoader), that classloader won't ever get garbage collected.
> I'm testing it by leaving a weak reference to the classloader and then
> forcing a system gc. If I don't call Class.forName, it gets collected
> happily. If I call Class.forName, it doesn't. Test case attached.
>
> Snooping in classpath's Class.forName points straight to
> VMClass.forName. VMClass.forName is native, so I assume that's where
> jamvm kicks in. Hence this email. If I'm wrong, I'll happily repost to
> the classpath list.
>
> Cheers
>
> Tom
>
>
>