harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Peter Edworthy" <pe...@edworthy.org>
Subject Re: [Arch] Class unloading and VM objects reclaim
Date Thu, 08 Sep 2005 14:51:08 GMT

I don't see why both methods of memory allocation and clean up may not be
employed. The classLoader may manage it's own memory area and create
objects that only it uses in the main memory area. The main memory area
objects would be true objects and be gc'ed just like normal (So long as
the class/classloader was given an object sig and registered it's creation
and release of these like any normal object would) and the local memory
would be freed when the class/classLoader was removed.

> Btw, there are some situations I am not sure if the approach you
> mentioned is possible. For example, we may want to reclaim also VM
> structures for strings that is not associated with a class loader, or
> to reclaim some jitted code buffers before the class loader is
> unloaded, or sometimes we want to put certain data/codes closely
> together for better cache/branch effects. Suggestions?
[shot version]
I don't think any of these are particularly 'hard' problems in creating a
JVM with efficient memory use.
[/short version]

[long version]
Cleaning up Strings that are only used in a particular classloader has a
slight catch; because of the 'Strings containing the same characters are
the same object' clause. This requires keeping a list of all currently
created String objects that is checked at String object creation time to
see if a reference to an existing object should be used or a new String
object created. This list has to be outside of the gc link checking or no
String would be gc'ed, but the list must also be informed when a String is
gc'ed so as to remove it.

If the classloader uses String objects it must either create them in the
main environment and gc will be taken care of as normal; or if the Strings
are only available to the classloader (breaking the equality rule) they
may be stored however the classloader wishes.

I don't see a problem with either of these methods and both will result in
the eventual gc of the memory.

Any buffers used in the JVM will be a separate issue of how they are
managed. I assume you are referring to IO buffers. If these are being
handled by the JVM then the JVM will have methods to request a buffer and
to return it, the classloader can use these or create a normal BufferedIO
object that will carryout the same functions when created and gc'ed. Again
if the buffers are the Classloaders then it can do what it likes, so long
as it is in it's space.

Caching should be handled just by the nature of a cache. If the
Classloader has gone then anything that is cached from it will not be
referenced anymore and so the cache will not receive requests for the copy
and will eventually re-use the space.

The only time I can see a problem for this is that potentially secret
information may continue to exist in a cache after the object has been
destroyed. For the moment as we are not proposing adding extensions to
Java to handle memory scrubbing this happens already as gc'ing an object
only removes the ptr to the memory area it does not change what is there,
until that area is reallocated and used.
[/long version]

This also brings up questions as to if we want to control all memory
allocation in the JVM instance, simply using the OS to increase and
decrease the JVM size or if the OS will be used to assign separate memory
areas to separate pieces of the JVM?

Thanks in advance,

View raw message