1

I'm working on fixing the issue 

java.lang.OutOfMemoryError: Metaspace

in the time of redeploy where running an web application (Apache Roller, Java EE weblogger software: https://roller.apache.org) on Tomcat 8.0.18.

I know the cause of the issue can be found via Eclipse Memory Analyzer, so I have got a heap dump in the time of OOME, that produced automatically by the JVM which running with 

-XX:+HeapDumpOnOutOfMemoryError.

I can see there are 4 WebappClassLoader instances that should be garbage collected. but I'm not sure why these instances hasn't be garbage collected. enter image description here

So here's my questions in Merge Shortest Paths to GC Roots => exclude all phantom/weak/soft/etc. references screen for each WebappClassLoader instances:

  1. Does this mean PostgreSQL JDBC Driver (deployed on the server side) has a reference to RollerContext? enter image description here

  2. This looks like a instance of SoftEntryReference has a reference to WebappClassLoader, but I guess it is not a strong reference so it doesn't prevent theWebappClassLoader to be garbage collected. am I wrong? enter image description here

  3. I have no idea what this means... What does this mean? Does WebappClassLoader itself prevents to be garbage collected? enter image description here

  4. Like I wrote in 2, I guess it should be garbage collected because it's referenced by a SoftReference. Am I wrong? enter image description here

Iamat8
  • 3,888
  • 9
  • 25
  • 35
Kohei Nozaki
  • 1,154
  • 1
  • 13
  • 36

1 Answers1

0

Does this mean PostgreSQL JDBC Driver (deployed on the server side) has a reference to RollerContext?

Yes, it would seem so. Specifically by an exception object's backtrace held in a static variable.

Merge Shortest Paths to GC Roots => exclude all phantom/weak/soft/etc. references

[...]

This looks like a instance of SoftEntryReference has a reference to WebappClassLoader, but I guess it is not a strong reference

[...]

Like I wrote in 2, I guess it should be garbage collected because it's referenced by a SoftReference. Am I wrong?

You're wrong.

You're not looking at soft references as far as the garbage collector is concerned. Only one field in a soft reference object is not-strong and that's the referent field.

Looking inside the JDK's java.lang.ref.Reference<T> class you will see that there are other fields. And you will also note that SoftReference is subclassable and thus can have additional fields. All non-referent fields are strong references.

MAT indicates that the stuff you're looking at is held by chains of discovered fields, which means the reference objects are certainly held alive, even if their referent has possibly been reclaimed.

I have no idea what this means... What does this mean? Does WebappClassLoader itself prevents to be garbage collected?

This is explained in the eclipse docs: It's a GC root because a lock is held on that object and because it's currently handled by native code, e.g. JNI.

It's the first google result for "eclipse mat busy monitor". Please do your research.

Community
  • 1
  • 1
the8472
  • 40,999
  • 5
  • 70
  • 122
  • As to 1, Now I suspect it's a bug of JDBC driver, so I reported about it to the pgsql-jdbc mailing list: http://www.postgresql.org/message-id/561B9D78.8090106@nailedtothex.org . As to other issues, I understand through your great explanation but still don't know what makes these strong references or Busy Monitor. How do you think about that? – Kohei Nozaki Oct 12 '15 at 12:03
  • 1
    4 is kept alive by thread-locals (logger scheduler thread). replacing the thread with a new one should solve that, so should shutting down its thread pool. one of the classloaders is presumably the latest one, i.e. one that *should* be alive. and the soft references may linger if they're used by a reference queue that doesn't get drained. You might have to explore the object graph beyond the shortest paths to the roots to see what those objects belong to. I.e. the shortest path may just be coincidental/transient and some other path to a GC root keeps it alive in the long term. – the8472 Oct 12 '15 at 12:15
  • 1
    as a last resort there always is the option of using reflection to dig through references and null out those that are troublesome. but that's easy to get wrong and brittle when the libraries on which you do reflection change. – the8472 Oct 12 '15 at 12:17
  • Now I guess that it may related to an issue of Google Guice that causes classloader leak when it is deployed with a web app (e.g. http://stackoverflow.com/questions/8842256/guice-3-0-tomcat-7-0-classloader-memory-leak). I would report about it if I can investigate it further. – Kohei Nozaki Oct 12 '15 at 12:40