Hello, 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, Peter
