JDK-6701887 : JDK7 server VM in endless loop between Node::dominates and Node::find_exact_control
  • Type: Bug
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: 7
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • OS: solaris_10
  • CPU: x86
  • Submitted: 2008-05-14
  • Updated: 2010-04-03
  • Resolved: 2008-06-12
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 6 JDK 7 Other
6u14Fixed 7Fixed hs13Fixed
Related Reports
Relates :  
For the past several days my solaris-i586 build machine has been falling into a tight loop while running pack200.  /opt/sfw/bin/top shows:

load averages:  3.57,  2.88,  5.18                                     12:28:48
72 processes:  64 sleeping, 6 running, 1 zombie, 1 on cpu
CPU states:  0.0% idle, 49.8% user, 50.2% kernel,  0.0% iowait,  0.0% swap
Memory: 3327M real, 2384M free, 160M swap in use, 6134M swap free

  20993 otto      11  53    2   84M   84M run    457:15 49.71% pack200

This is using a server VM built from the hotspot master repository.

% pargs 20993
20993:  /u/auto/jdk/7/build/130/bin/pack200 -J-esa -J-ea -J-Xmx512m --no-gzip --config-
argv[0]: /u/auto/jdk/7/build/130/bin/pack200
argv[1]: -J-esa
argv[2]: -J-ea
argv[3]: -J-Xmx512m
argv[4]: --no-gzip
argv[5]: --config-file=pack.all.properties
argv[6]: --code-attribute=StackMapTable=strip
argv[7]: /u/auto/jdk/7/build/130/pack/pack-jdk-jars/jre/lib/jsse.pack
argv[8]: /u/auto/jdk/7/build/130/j2sdk-image/jre/lib/jsse.jar

attaching to the process with dbx shows this:

(dbx) threads
  >    t@1  a  l@1   ?()   running          in  __lwp_wait()
       t@2  a  l@2   JavaMain()   running          in  ___lwp_cond_wait()
       t@3  b  l@3   java_start()   running          in  ___lwp_cond_wait()
       t@4  b  l@4   java_start()   running          in  ___lwp_cond_wait()
       t@5  b  l@5   java_start()   running          in  TryFast()
       t@6  b  l@6   java_start()   running          in  ___lwp_cond_wait()
       t@7  b  l@7   java_start()   running          in  ___lwp_cond_wait()
       t@9  b  l@9   java_start()   running          in  ___lwp_cond_wait()
      t@10  b l@10   java_start()   running          in  dominates()
      t@11  b l@11   java_start()   running          in  ___lwp_cond_wait()
      t@13  b l@13   umem_update_thread()   sleep on (unknown) in  __lwp_park()
(dbx) thread t@10
t@10 (l@10) stopped in Node::dominates at 0xfeaddc89
0xfeaddc89: dominates+0x00ad:   je       dominates+0x1d5        [ 0xfeadddb1, .+0x128 ]
(dbx) where
current thread: t@10
=>[1] Node::dominates(0x959b1bc, 0x8e26ba4, 0xd6b9bbc0), at 0xfeaddc89
   [2] MemNode::all_controls_dominate(0x959b1fc, 0x8d9cd34), at 0xfeac595f
   [3] InitializeNode::detect_init_independence(0x8d9cd34, 0x959b1fc, 0x1, 0xd6b9bddc), at 
   [4] InitializeNode::detect_init_independence(0x8d9cd34, 0x959d7e0, 0x1, 0xd6b9bddc), at 
   [5] InitializeNode::detect_init_independence(0x8d9cd34, 0x8e1ab40, 0x1, 0xd6b9bddc), at 
   [6] InitializeNode::detect_init_independence(0x8d9cd34, 0x8e1bbec, 0x1, 0xd6b9bddc), at 
   [7] InitializeNode::detect_init_independence(0x8d9cd34, 0x8e1cfbc, 0x1, 0xd6b9bddc), at 
   [8] InitializeNode::detect_init_independence(0x8d9cd34, 0x8d9c724, 0x1, 0xd6b9bddc), at 
   [9] InitializeNode::can_capture_store(0x8d9cd34, 0x8d9dd6c, 0xd6b9bee0), at 0xfeaca71f
   [10] StoreNode::Ideal(0x8d9dd6c, 0xd6b9bee0, 0x1), at 0xfeac909f
   [11] PhaseIterGVN::transform_old(0xd6b9bee0, 0x8d9dd6c), at 0xfe69d99b
   [12] PhaseIterGVN::optimize(0xd6b9bee0), at 0xfe716bed
   [13] Compile::Optimize(0xd6b9d558), at 0xfe7571f9
   [14] Compile::Compile(0xd6b9d558, 0xd6b9da50, 0x808eae8, 0x9556010, 0xffffffff, 0x1, 0x0), 
at 0xfe90e009
   [15] C2Compiler::compile_method(0x808eae8, 0xd6b9da50, 0x9556010, 0xffffffff), at 0xfe754036
   [16] CompileBroker::invoke_compiler_on_method(0x8364e88), at 0xfe7545bb
   [17] CompileBroker::compiler_thread_loop(0xfecd8000, 0x98, 0xd6b9dc48, 0xfe77d3e8, 
0x81b9800, 0x81b9800), at 0xfe7b3dfc
   [18] compiler_thread_entry(0x81b9800, 0x81b9800), at 0xfe7b5cdc
   [19] JavaThread::thread_main_inner(0x81b9800), at 0xfe77d3e8
   [20] JavaThread::run(0x81b9800), at 0xfe77d392
   [21] java_start(0x81b9800), at 0xfeae3921
   [22] _thr_setup(0xfb081c00), at 0xfeedfc32
   [23] _lwp_start(), at 0xfeedff20

If I stepi this thread it goes into find_exact_control, comes back out, and repeats.

Unfortunately I have not been able to reproduce this at will from the command line - it is only happening during my nightly build.

The lab system is baozi.sfbay.  Interactive response is poor when the process is running, but you will eventually get a prompt.

There are several core files, pargs output, and notes under /var/tmp/tbell/<pid>

SUGGESTED FIX Solution: Restore the iterations limit for a control path which doesn't have a Region node. Set it to 1000 since the method in jvm98 has a normal control path size 209 nodes: spec.benchmarks._205_raytrace.OctNode::CreateFaces() (643 bytes) Also fixed 2 problems in the original 6686791 changes.

EVALUATION Dead control loop without Region node: =>[1] Node::dominates(0x98e8ee8, 0x990dc6c, 0xd58f5208), at 0xfdec2763 [2] MemNode::all_controls_dominate(0x98e8f3c, 0x9e425e0), at 0xfde5c6df [3] InitializeNode::detect_init_independence(0x9e425e0, 0x98e8f3c, 0x1, 0xd58f55dc), at 0xfde68ce8 sub: _ / \ | iF | | | ifTrue | | | SafePoint | | | iF | | | ifTrue | | \_/ [t@10 l@10]: x 0x990dc6c/8 0x0990dc6c: 0xfed1d468 0x0990dcac 0x0990dddc 0x00000002 0x0990dc7c: 0x00000002 0x00000002 0x00000004 0x0000046c [t@10 l@10]: x 0xfed1d468 0xfed1d468: __1cGIfNodeG__vtbl_ : 0xfe50445c [t@10 l@10]: x 0x0990dcac/2 0x0990dcac: 0x09ee02e8 0x0990dc18 [t@10 l@10]: x 0x09ee02e8/8 0x09ee02e8: 0xfed1d3ec 0x09ee0328 0x09ee032c 0x00000001 0x09ee02f8: 0x00000001 0x00000002 0x00000004 0x00001177 [t@10 l@10]: x 0xfed1d3ec 0xfed1d3ec: __1cKIfTrueNodeG__vtbl_ : 0xfe5043d8 [t@10 l@10]: x 0x09ee0328/2 0x09ee0328: 0x09ee023c 0x0990f240 [t@10 l@10]: x 0x09ee023c/8 0x09ee023c: 0xfed1d468 0x09ee027c 0x09ee02d8 0x00000002 0x09ee024c: 0x00000002 0x00000002 0x00000004 0x00001175 [t@10 l@10]: x 0x09ee027c/2 0x09ee027c: 0x0990ebfc 0x09ee01f8 [t@10 l@10]: x 0x0990ebfc/8 0x0990ebfc: 0xfed101a8 0x0990ec9c 0x0990ed3c 0x00000019 0x0990ec0c: 0x00000028 0x00000001 0x00000004 0x0000048b [t@10 l@10]: x 0xfed101a8 0xfed101a8: __1cNSafePointNodeG__vtbl_ : 0xfe450090 [t@10 l@10]: x 0x0990ec9c/2 0x0990ec9c: 0x0990dd98 0x0827c708 [t@10 l@10]: x 0x0990dd98/8 0x0990dd98: 0xfed1d3ec 0x0990ddd8 0x0990ddec 0x00000001 0x0990dda8: 0x00000001 0x00000001 0x00000004 0x0000046f [t@10 l@10]: x 0xfed1d3ec 0xfed1d3ec: __1cKIfTrueNodeG__vtbl_ : 0xfe5043d8 [t@10 l@10]: x 0x0990ddd8/2 0x0990ddd8: 0x0990dc6c 0x0990dd98