United StatesChange Country, Oracle Worldwide Web Sites Communities I am a... I want to...
Bug ID: JDK-6701887 JDK7 server VM in endless loop between Node::dominates and Node::find_exact_control
JDK-6701887 : JDK7 server VM in endless loop between Node::dominates and Node::find_exact_control

Details
Type:
Bug
Submit Date:
2008-05-14
Status:
Resolved
Updated Date:
2010-04-03
Project Name:
JDK
Resolved Date:
2008-06-12
Component:
hotspot
OS:
solaris_10
Sub-Component:
compiler
CPU:
x86
Priority:
P3
Resolution:
Fixed
Affected Versions:
7
Fixed Versions:
hs13 (b02)

Related Reports
Backport:
Backport:
Relates:

Sub Tasks

Description
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

    PID USERNAME LWP PRI NICE  SIZE   RES STATE    TIME    CPU COMMAND
  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 
0xfeaca5c2
   [4] InitializeNode::detect_init_independence(0x8d9cd34, 0x959d7e0, 0x1, 0xd6b9bddc), at 
0xfeaca633
   [5] InitializeNode::detect_init_independence(0x8d9cd34, 0x8e1ab40, 0x1, 0xd6b9bddc), at 
0xfeaca633
   [6] InitializeNode::detect_init_independence(0x8d9cd34, 0x8e1bbec, 0x1, 0xd6b9bddc), at 
0xfeaca633
   [7] InitializeNode::detect_init_independence(0x8d9cd34, 0x8e1cfbc, 0x1, 0xd6b9bddc), at 
0xfeaca633
   [8] InitializeNode::detect_init_independence(0x8d9cd34, 0x8d9c724, 0x1, 0xd6b9bddc), at 
0xfeaca633
   [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>

                                    

Comments
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
                                     
2008-05-14
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.
                                     
2008-05-16



Hardware and Software, Engineered to Work Together