CODEWITHSUNDEEP
memory-leaksjaxbjava-8out-of-memorymetadata
Bassam
Bassam

Reputation: 146

How to analyze memory leaks in Java 8 compressed class space?

Some Context: We have upgraded the environment of a web application from running on Java 7 to running on Java 8 and Tomcat 8 (64-bit arch, Heap size about 2 GB, PermGen size=256 MB, no constraints on metaspace size). After a while, we started getting the following error:

java.lang.OutOfMemoryError: Compressed class space

which means that the space needed for UseCompressedClassPointers exceeded CompressedClassSpaceSize. At that moment VisualVM showed a 2 GB metaspace size.

Now with the VisualVM tool, we can see the Metaspace size is constatnly increasing with every request about 3 MB, however the heap does not seem to do so. The heap usage has a saw zigzag shape going back to the same low point after every GC.

I can tell that the application is leaking Metadata only when using a Java JAXB operation, but I couldn't prove it with VisualVM.

The application depends on webservices-rt-1.4 as a JAXB implementation provider. The application uses marshalling, unmarshalling. The class generation from XSD is done with maven-jaxb2-plugin-0.13.1.

Update:

After tracing class loading and unloading, I found out that the same JAXB classes is loaded into memory by WebAppClassLoader multiple times but never cleaned up. Moreover, there are no instances to them in the heap. I debugged and I saw that JDK is calls the method javax.xml.bind.JAXBContext com.sun.xml.bind.v2.ContextFactory.createContext by reflection and that's when the class are created.

I though the classes are cleaned up by GC. Is it the responsibility of the classLoader to clean up?

Questions: Is there a way to analyze the metaspace objects? Why do I have a leak in metaspace but not in heap? aren't they related? Is that even possible?

Why would the app work fine with PermGen but not Metaspace?

Upvotes: 5

Views: 7544

Answers (2)

maki888
maki888

Reputation: 96

I am facing similar issue.

In my case, memory leak was caused by JAXBContext.newInstance(...) invoke.

Solutions:

Upvotes: 8

harsha v
harsha v

Reputation: 21

I had similar issue and adding -Dcom.sun.xml.bind.v2.bytecode.ClassTailor.noOptimize=true in setenv.sh as JVM OPT arguments it resolve OOM metaspace issue.

Upvotes: 2

Related Questions