Details
Description
JikesRVM should unload classes that are no longer in use. I finally have a benchmark that needs it ![]()
One of the candidate benchmarks for the next release of dacapo is Apache Derby. When running the PseudoJDBCBench benchmark with Derby, dynamic SQL statements such as
Stmt.executeUpdate("UPDATE tellers SET Tbalance = Tbalance + " + delta + " WHERE Tid = " + tid);
result in on-the-fly creation of classes, eventually resulting in the JTOC filling up and the world ending. Running hotspot with the same benchmark and -verbose:class, we see this kind of thing
[Loaded org.apache.derby.exe.acc87100b8x0115xea15x7ebex00000026a740c4 from org.apache.derby.impl.services.reflect.ReflectLoaderJava2]
[Loaded org.apache.derby.exe.acc87100b8x0115xea15x7ebex00000026a740c5 from org.apache.derby.impl.services.reflect.ReflectLoaderJava2]
[Unloading class org.apache.derby.exe.ac6dd780d4x0115xea15x7ebex00000026a74043]
[Unloading class org.apache.derby.exe.ac1d6e40d2x0115xea15x7ebex00000026a74061]
The problem can be reproduced by
svn co https://dacapobench.svn.sf.net/svnroot/dacapobench/benchmarks/trunk dacapo
cd dacapo
ant derby.source
ant derby jar.quick
rvm -jar dacapo.jar derby
We need to do this, it's a fundamental bit of underlying RVM design that is wrong. From my pov I think we need to associate statics with classes and possibly do something more akin to how JNI passes around classes with static methods. We still need the JTOC for certain literals, but some of these should be either associated with a class or class loader. The cost of this needn't be devastating as classes are literals that we can fold away. Obviously we also need to hang compiled methods off of classes/class loaders to make some of this work. It's likely to have quite severe performance implications. There is also the question as to whether we can use weak references to make the reclamation of the class loader automatic, or whether we need to hand craft GC support for unloading classes.
I think this is a big job and shouldn't be scheduled for the release of 3.0 unless someone is prepared to take charge of it.
Related issues from SF's RFE tracker:
1571462: Replace JTOC with per-classloader static segments
https://sourceforge.net/tracker/index.php?func=detail&aid=1571462&group_id=128805&atid=712771
1571374: Type dictionaries should be per-classloader, not global
https://sourceforge.net/tracker/index.php?func=detail&aid=1571374&group_id=128805&atid=712771
1147162: Reduce JTOC pressure of constants/static final fields
https://sourceforge.net/tracker/index.php?func=detail&aid=1147162&group_id=128805&atid=712771