0

My java application is frequently used in fullgc. I use jmap -dump:file=xxx to get a heap file. After using the mat tool for analysis, I can't find the problem, but I find that there are many 'unreachable_ Objects' is about 1g. I want to know which code generates so many garbage objects, but mat can't see the details. It can only see the byte[] type. How do I find references to these bytes[]?

Here is my JVM configuration

-server -Xmx6g -Xms6g -XX:NewRatio=2 -XX:+UseConcMarkSweepGC -XX:CMSInitiatingOccupancyFraction=75 -XX:+UseCMSInitiatingOccupancyOnly -XX:MaxTenuringThreshold=6 -XX:+ParallelRefProcEnabled -XX:+CMSParallelRemarkEnabled -XX:+UseCMSCompactAtFullCollection -XX:+HeapDumpOnOutOfMemoryError -XX:MetaspaceSize=512m -XX:MaxMetaspaceSize=512m -XX:+PrintGCDetails -XX:+PrintGCDateStamps -Xloggc:/export/Logs/gc.log

Environment

The mat picture is as follows

unreachable_objects

Object histogram

Feng Kai
  • 21
  • 3
  • Which JVM do you use? And if J9, what type of heap dump file? Next, the unreachable objects are not the problem, assuming that you did not play around with the GC settings. In the opposite, somewhere in your code, you allocate large chunks of memory in one go that forces the GC into "emergency mode" to collect any available byte from heap, as it was otherwise not able to fullfill the memory allocation request. – tquadrat Jun 15 '22 at 06:47
  • What should i do to avoid full gc? – Feng Kai Jun 15 '22 at 07:23
  • 1
    “references to unreachable objects” is a contradiction. It’s impossible to find them, as “unreachable” implies the absence of references. Besides that, you intervened in the garbage collector configuration a dozen times, so you must be a CMS expert rather than someone who has to ask strangers on the internet about it, right? I see the following options: 1) try to run the JVM with the default options 2) try to use G1GC instead of the outdated CMS, again, using the default options rather than some “best options” copied from somewhere. – Holger Jun 15 '22 at 08:49
  • @Holger – The *heap dump* ***has*** "references to unreachable objects". Whether these are only in the heap dump (or defined only by the heap dump analyser tool), or if they are maintained by the JVM to simplify the garbage collection is a different kettle of fish. – tquadrat Jun 15 '22 at 10:34
  • 1
    @tquadrat when there are references to an object, the object is not unreachable. But indeed, if the heap analyzer showed references to these objects, it wouldn’t matter whether they are real or invented by the analyzer tool, as in either case, the OP had no problem in finding them. Obviously, the OP’s problem is that no references are shown. – Holger Jun 15 '22 at 10:45
  • @Holger – He see the references, but no details, because the heap dump does not provide the data, only the references (at least I understood that). This is a common problem when using phd format from J9, while the Sun format has the values of primitives and arrays (so that you also have the values of Strings). – tquadrat Jun 15 '22 at 11:29
  • 1
    @tquadrat maybe we should first agree on the terminology. The unreachable **objects** are included, whether with details or without, but the **references to** these objects don’t exist, per definition, as otherwise, the heap dump analyzer didn’t categorize them as **unreachable**. Note that the OP uses the HotSpot JVM and hprof format, so missing details is not the issue. As noted in my first comment, it always raises my suspicion if a problematic environment has lots of explicit GC options, the OP can’t explain. The first thing to check, is whether those options are the cause of the problem… – Holger Jun 15 '22 at 11:47

0 Answers0