[#RVM-324] Implement class unloading

RVM

Implement class unloading

Created: 28/Oct/07 11:54 PM Updated: 12/Feb/09 08:41 AM

Component/s:

Runtime

Affects Version/s:

2.9.0, 2.9.0.1, 2.9.1, 2.9.2

Fix Version/s:

1000

Time Tracking:

Not Specified

Issue Links:

Related

This issue relates to:

~~RVM-371~~ 13956 broke PPC64 development build

This issue is related to:

~~RVM-445~~ Clean up handling of JTOC

~~RVM-375~~ VM_Static and VM_Atom keys use ~540kb of the boot image

Testcase included:

yes

Description

« Hide

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

All

Comments

Work Log

Change History

Sort Order:

[ Permalink | « Hide ]

Ian Rogers added a comment - 29/Oct/07 03:28 AM

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

[ Permalink | « Hide ]

David Grove added a comment - 29/Oct/07 07:22 AM

Moving off of 3.0 fix target.

This is a major piece of re-engineering. We should do it, but we should also expect it to take months if we want to do it "right" since pretty much all of the global data structures of the VM would need to be redone to localize entries on a per-classloader basis.

It will also have rippling impact on PPC, since it probably means we have to abandon the simple "all global data is in the jtoc" strategy and PPC doesn't have as efficient ISA support for address literals as IA32 does.

[ Permalink | « Hide ]

Ian Rogers added a comment - 10/Feb/08 02:11 AM

The size of the hash maps in VM_Statics is causing us to go over the boot image size. Ideally we'd like to remove the hashmaps and just use an efficient search of the JTOC. We're discussing how literals should be organized. As literals are pulled in during the class loading process, possibly we want to think about how changes to the literals can fit in with class unloading.

[ Permalink | « Hide ]

Ian Rogers added a comment - 28/May/08 10:07 AM

One way to handle literals is to place them with the code they represent, this would allow visibility using instruction pointer relative addressing.

[ Permalink | « Hide ]

Ian Rogers added a comment - 12/Feb/09 08:41 AM

An inefficient way to avoid placing a reference to a class in the header of the compiled code is to:

1) get the CMID
2) use the CMID to look up the compiled method
3) from the compiled method lookup the method
4) from the method get the class
5) from the class get the statics or literals

Problems with placing a class reference in the header to compiled code are:

1) object model layout
2) IA32 and PowerPC have no direct way to get the program counter/instruction pointer (Q: are static accesses so rare we can ignore this?)

When tracing we need to start with the active compiled code and see what classes and thereby class loaders are reachable.