5

I have a java application which used to run fine with java 7. After migrating to java 8 with the following confiugration it started to hang. 

-Xms3g -Xmx3g -verbose:gc -XX:+UseG1GC -XX:G1ReservePercent=25 -XX:+PrintGCDateStamps

I have taken jstack dump and it shows that all threads are in BLOCKED state. I also have taken jmap dump which shows the following information.

Can someone help me in resolving this issue?

Attaching to process ID 2554, please wait...
Debugger attached successfully.
Server compiler detected.
JVM version is 25.74-b02

using thread-local object allocation.
Garbage-First (G1) GC with 18 thread(s)

Heap Configuration:
   MinHeapFreeRatio         = 40
   MaxHeapFreeRatio         = 70
   MaxHeapSize              = 3221225472 (3072.0MB)
   NewSize                  = 1363144 (1.2999954223632812MB)
   MaxNewSize               = 1932525568 (1843.0MB)
   OldSize                  = 5452592 (5.1999969482421875MB)
   NewRatio                 = 2
   SurvivorRatio            = 8
   MetaspaceSize            = 21807104 (20.796875MB)
   CompressedClassSpaceSize = 1073741824 (1024.0MB)
   MaxMetaspaceSize         = 17592186044415 MB
   G1HeapRegionSize         = 1048576 (1.0MB)

Heap Usage:
G1 Heap:
   regions  = 3072
   capacity = 3221225472 (3072.0MB)
   used     = 2112667712 (2014.7969360351562MB)
   free     = 1108557760 (1057.2030639648438MB)
   65.58583776156108% used
G1 Young Generation:
Eden Space:
   regions  = 1665
   capacity = 2024800256 (1931.0MB)
   used     = 1745879040 (1665.0MB)
   free     = 278921216 (266.0MB)
   86.22475401346452% used
Survivor Space:
   regions  = 5
   capacity = 5242880 (5.0MB)
   used     = 5242880 (5.0MB)
   free     = 0 (0.0MB)
   100.0% used
G1 Old Generation:
   regions  = 349
   capacity = 1191182336 (1136.0MB)
   used     = 361545792 (344.79693603515625MB)
   free     = 829636544 (791.2030639648438MB)
   30.351842960841218% used

18753 interned Strings occupying 1751224 bytes.
Vikrant Kashyap
  • 6,398
  • 3
  • 32
  • 52
James
  • 51
  • 2
  • 3
    Your Eden space is quite busy and your Survivor Space is full, this is fairly normal - the Old Gen is quite empty. I would run again with either 1) print GC flags set, or 2) VisualVM attached. – Boris the Spider Apr 14 '16 at 07:17
  • 2
    Does it hang without any flags set? – Thorbjørn Ravn Andersen Apr 14 '16 at 07:18
  • Is it fully your app or does it run on a container? (Application server, OSGi container, ...) – gusto2 Apr 14 '16 at 07:22
  • Can you try running with the following flags as well and share output. -XX:+PrintGC -XX:+PrintGCDetails -XX:+PrintGCTimeStamps -Xloggc:mygclogfilename.gc – The Roy Apr 14 '16 at 07:28
  • @GabrielVince This is a standalone application. – James Apr 14 '16 at 07:38
  • 4
    It sounds like you have a thread safety bug. You can write code which happens to work in one version on one machine, but change the OS, the machine or the JVM version and your bug can show up. If all your threads are BLOCKED they are waiting for something. – Peter Lawrey Apr 14 '16 at 07:39
  • @DROY I will set GC flag and shre the result. – James Apr 14 '16 at 07:50
  • Any chance you could post the tread dump - if @PeterLawrey is correct then it should be fairly simple to at least work out which monitor the threads are waiting for. You could also try [deadlock detection](http://stackoverflow.com/a/8126828/2071828) in VisualVM. – Boris the Spider Apr 14 '16 at 09:31
  • This issue is not reproduced yet. I will update once this issue is reproduced. – James Apr 19 '16 at 07:19

1 Answers1

0

You need to take a thread dump and analyze it carefully to understand where they are stuck, it is most likely thread safety issue in your code. We have faced similar locking issue in the past when we moved from Linux 4 machine to Linux 6 (much powerful machine with multiple CPU and cores). Faster machines can expose such long standing threading related programming bugs.

Chetan K
  • 31
  • 1