1

I have a Maven build which appears to have a leak occasionally making the Java process run out of PermGen memory (EDIT) and I have learned from VisualVM that the heap and PermGen increases notably whenever a new is built. Now I would like to find out where the leak is (EDIT: and not just get rid of the occasional exception).

It appears that the standard approach to this is to let HPROF collect data for post-mortem analysis. This fails for me, however, and the generated java.hprof file cannot be parsed correctly by tools.

My "mvn.bat" file looks like (a 64-bit JVM on Windows 7):

set JAVA_HOME=c:\Program Files\java\jdk1.7.0_11
C:\Users\TRA\progs\apache-maven-3.0.4\bin\mvn %*

My MAVEN_OPTS look like

MAVEN_OPTS=-agentlib:hprof=format=b

and this is the result of a "mvn clean".

[INFO] ------------------------------------------------------------------------
[INFO] Total time: 9.589s
[INFO] Finished at: Fri Feb 08 12:46:26 CET 2013
[INFO] Final Memory: 8M/154M
[INFO] ------------------------------------------------------------------------
Dumping Java heap ...
HPROF LIST OF ALL FIELDS:
[1] Lsun/reflect/UnsafeFieldAccessorImpl; "field" "Ljava/lang/reflect/Field;"(ty=OBJ) val=[0x00000000,0x500007e0] or [0x00000000,0x500007e0]
[2] Lsun/reflect/UnsafeFieldAccessorImpl; "fieldOffset" "I" (primType=73(I)) val=[0x00000007,0x00000070] or [0x00000007,0x00000070]
[3] Lsun/reflect/UnsafeFieldAccessorImpl; "isFinal" "Z" (primType=90(Z)) val=[0x00000007,0x7ae16501] or [0x00000007,0x7ae16501]
[4] Lsun/reflect/UnsafeStaticFieldAccessorImpl; "base" "Ljava/lang/Object;"(ty=OBJ)
[5] Lsun/reflect/UnsafeQualifiedStaticFieldAccessorImpl; "isReadOnly" "Z" (primType=90(Z))

FOLLOW REFERENCES RETURNED:
[1]: flavor=1, refKind=2, primType=0, object_index=0x500007e0, length=-1, next=0xb0013852
[2]: flavor=2, refKind=2, primType=73, object_index=0x0, length=-1, next=0xb0013851
[3]: flavor=2, refKind=2, primType=90, object_index=0x0, length=-1, next=0xb0013850
[4]: flavor=2, refKind=2, primType=90, object_index=0x0, length=-1, next=0x0

PROBLEM WITH:
[4] Lsun/reflect/UnsafeStaticFieldAccessorImpl; "base" "Ljava/lang/Object;" (primType=0( ), got 90(Z)) val=[0x00000007,0x7ae16501] or [0x00000000,0x00000000]

HPROF ERROR: Trouble with fields and heap data [hprof_reference.c:281]

HPROF LIST OF ALL FIELDS:
[1] Lsun/reflect/UnsafeFieldAccessorImpl; "field" "Ljava/lang/reflect/Field;"(ty=OBJ) val=[0x00000000,0x500007e1] or [0x00000000,0x500007e1]
[2] Lsun/reflect/UnsafeFieldAccessorImpl; "fieldOffset" "I" (primType=73(I)) val=[0x00000007,0x00000074] or [0x00000007,0x00000074]
[3] Lsun/reflect/UnsafeFieldAccessorImpl; "isFinal" "Z" (primType=90(Z)) val=[0x00000007,0x7b2c1001] or [0x00000007,0x7b2c1001]
[4] Lsun/reflect/UnsafeStaticFieldAccessorImpl; "base" "Ljava/lang/Object;"(ty=OBJ)
[5] Lsun/reflect/UnsafeQualifiedStaticFieldAccessorImpl; "isReadOnly" "Z" (primType=90(Z))

FOLLOW REFERENCES RETURNED:
[1]: flavor=1, refKind=2, primType=0, object_index=0x500007e1, length=-1, next=0xb0013836
[2]: flavor=2, refKind=2, primType=73, object_index=0x0, length=-1, next=0xb0013835
[3]: flavor=2, refKind=2, primType=90, object_index=0x0, length=-1, next=0xb0013834
[4]: flavor=2, refKind=2, primType=90, object_index=0x0, length=-1, next=0x0

PROBLEM WITH:
[4] Lsun/reflect/UnsafeStaticFieldAccessorImpl; "base" "Ljava/lang/Object;" (primType=0( ), got 90(Z)) val=[0x00000007,0x7b2c1001] or [0x00000000,0x00000000]

HPROF ERROR: Trouble with fields and heap data [hprof_reference.c:281]

HPROF LIST OF ALL FIELDS:
[1] Lsun/reflect/UnsafeFieldAccessorImpl; "field" "Ljava/lang/reflect/Field;"(ty=OBJ) val=[0x00000000,0x5002f4a1] or [0x00000000,0x5002f4a1]
[2] Lsun/reflect/UnsafeFieldAccessorImpl; "fieldOffset" "I" (primType=73(I)) val=[0x00000007,0x00000070] or [0x00000007,0x00000070]
[3] Lsun/reflect/UnsafeFieldAccessorImpl; "isFinal" "Z" (primType=90(Z)) val=[0x00000007,0x7ae16501] or [0x00000007,0x7ae16501]
[4] Lsun/reflect/UnsafeStaticFieldAccessorImpl; "base" "Ljava/lang/Object;"(ty=OBJ)
[5] Lsun/reflect/UnsafeQualifiedStaticFieldAccessorImpl; "isReadOnly" "Z" (primType=90(Z))

FOLLOW REFERENCES RETURNED:
[1]: flavor=1, refKind=2, primType=0, object_index=0x5002f4a1, length=-1, next=0xb0013a4b
[2]: flavor=2, refKind=2, primType=73, object_index=0x0, length=-1, next=0xb0013a4a
[3]: flavor=2, refKind=2, primType=90, object_index=0x0, length=-1, next=0xb0013a49
[4]: flavor=2, refKind=2, primType=90, object_index=0x0, length=-1, next=0x0

(and on and on and on). I am unfamiliar with hprof.

What is the best way to go on from here?

Thorbjørn Ravn Andersen
  • 73,784
  • 33
  • 194
  • 347
  • Can you show the pom file which causes the problem? Are you running unit tests or integration tests ? – khmarbaise Feb 08 '13 at 12:51
  • Unfortunately I cannot show the poms in question. There are a few tests but nothing heavy weight. I do not believe that _this_ problem is with maven directly but perhaps Guice or I am just trying to do something unsupported. – Thorbjørn Ravn Andersen Feb 08 '13 at 13:38
  • Try to add `-XX:-HeapDumpOnOutOfMemoryError` to `MAVEN_OPTS`. This should tell JVM to generate memory dump which can then be analyzed by profiler (like YourKit or VisualVM). – Andrew Logvinov Feb 08 '13 at 16:12

1 Answers1

0

The classical issue when switching to 64bits jvm from 32 bits ones is the PermGen exception.

When using a 64bits JVM you need a bigger PermGen size. Try to use something like MAVEN_OPTS="-XX:MaxPermSize=256m" or higher if needed.

I personnally use 512m or even 1g on big projects when building them with a 64bits jvm. Those same projects requires half that with 32bits jmvs.

Farid
  • 2,265
  • 18
  • 14
  • Apparently I have not been clear - I have already found that workaround to get work done. Now I want to figure out what the reason is, and apparently something is broken regarding hprof. – Thorbjørn Ravn Andersen Feb 08 '13 at 21:18