What causes a JRE 6 JVM code cache leak?

Question

Since switching to JRE 6, my server's code cache usage (non-heap) keeps growing indefinitely. My application creates a lot of classes at runtime, BUT these classes are successfully unloaded during the GC process. I can see these classes getting unloaded in the gc logs and also the permGen usage stays constant. I specifically make sure in my code that these classes are orphaned once I am finished with them and so they correctly get garbage collected from permGen.

The code cache however keeps growing. I only became aware of the code cache after switching to JRE 6. So I guess my questions are:

1. Does GC include the code cache?
2. What could cause a code cache memory leak, specifically.
3. Is there a bug in JDK 6 in this area?

Answer 1

Is it possible to invoke jvisualvm (in the JDK) against the troublesome application? It may easily make you much wiser about what is happening.

Answer 2

You may want to look through this discussion and just go backwards to see what may be helpful in trying to narrow this down: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2009-January/000530.html

This one involves JDK5 but may be helpful: http://www.nabble.com/Java-code-cache-memory-td22202283.html

Are you using this to compile jsp pages, or something similar? If not, what is being compiled after the application starts up? Are you using AspectJ with runtime weaving?

It would help to know what you are doing to get a better idea as to how to help.

Also, when the code cache is exhausted, does it just stop compiling anew or does the jvm crash? I would expect the former.

Are you using Sun's JDK? I am guessing you are since I doubt the others are listed as version 6, but it doesn't hurt to ask.

Answer 3

I was wondering if the new G1 Garbage Collector (as of Java 6 update 14) might help you. You can try it with -XX:+UnlockExperimentalVMOptions -XX:+UseG1GC, however according to comments on Jon Masamitsu's blog it won't (if the problem really is due to the code cache). But maybe the discussion there or the links from it might help.

Answer 4

From the comments in this blog post: http://blogs.sun.com/jonthecollector/entry/our_collectors

code is evicted when classes are unloaded (as well, as when methods are "invalidated", i.e., some assumptions were made during their compilation that do not hold any more)

if I were you I would run a workload, take a heap dump, and check whether all classes are gc'd that you expect to be.