Archie Cobbs wrote:
> Some "theoretical" questions... :-)
>
> Couldn't instances of the classes Class, Method, Field, and Constructor
> be stored in the per-ClassLoader memory area?
It could theoretically be so, but this means that we maintain a non-uniform Java
heap. SableVM's current brain-dead copying collector is totally uniform; no
pinned objects, no special heap areas, no special anything.
Of course, when you start implementing a generational collector, then it makes
kind of sense to start managing class-loader specific Java heaps. In fact, the
nice thing is that this special kind of generation needs no be garbage collected
ever (other than a complete free of all of the class-loader related memory, on
class unloading).
>
> Of course the GC would have to know not to move them, but overall
> this might be more efficient for applications that use reflection
> heavily.
>
> Also: it doesn't appear that SableVM supports unloading ClassLoader's.
> Is that correct?
Yes it is. You have to analyze the heap and static areas before deciding to
unload a complete class loader + all its resources. When you start thinking
about it seriously, you quickly discover that it has to be done very carefully.
I think we should get the rest of the VM more robust before getting into this
part.
> What would be required to do this? Seems like you
> could do it simply by adding a ClassLoader.finalize() native method
> which just free'd the per-ClassLoader memory blob and unloaded any
> native libraries.
>
> Hmm, talking to myself... java.lang.Object does not contain any
> field that references the object's Class object (nor should it for
> efficiency reasons). Therefore, Class objects must be referenced
> internally by the VM to be kept alive. However, since in SableVM
> these references must be global, the Class object can never be GC'd,
> and therefore it's ClassLoader object could never be GC'd, and so
> ClassLoaders could never be unloaded.
>
> Other "implicit" references include Class -> ClassLoader,
> Class -> Class (superclass or superinterface), etc...
>
> So, keeping stuff alive properly is more complicated...
>
> Also: does SableVM ever run Object.finalize()? I don't see where it does.
No. Now, this is something we should fix, but it is not critical; the VM spec
does not garantee that finalize() be executed. Now, I know we cheat when we
actually reuse a dead object's memory area to store new objects, but
theoretically, it is correct. Now, the fun thing will be to also implement
weak, soft, and phantom, while also respecting the life cycle of finalized
objects;-) [Just a lot of code to add to GC].
Etienne
>
> Thanks,
> -Archie
>
> __________________________________________________________________________
> Archie Cobbs * Packet Design * http://www.packetdesign.com
>
>
> -------------------------------------------------------
> This SF.NET email is sponsored by:
> SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
> http://www.vasoftware.com
> _______________________________________________
> Sablevm-developer mailing list
> Sab...@li...
> https://lists.sourceforge.net/lists/listinfo/sablevm-developer
>
>
--
Etienne M. Gagnon, Ph.D. http://www.info.uqam.ca/~egagnon/
SableVM: http://www.sablevm.org/
SableCC: http://www.sablecc.org/
|
