JDK-4838812 : Assertion in parseHelper.cpp:186 while running ecperf on S1AS 7
  • Type: Bug
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: 5.0
  • Priority: P3
  • Status: Closed
  • Resolution: Cannot Reproduce
  • OS: generic
  • CPU: generic
  • Submitted: 2003-03-27
  • Updated: 2004-02-02
  • Resolved: 2004-02-02
Related Reports
Relates :  
JDK-4827458 - Intermittent assertion failure running appserver 7 with mantis-beta on solsparc
Description
Vm assertion while running Sunone Appserver with fast-debug binariedes
Java Version: 
java version "1.5.0-beta"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0-beta-b02)
Java HotSpot(TM) Server VM (build 20030321101233.robertg.baseline-fastdebug-debug, mixed mode)

VM Options used:
 VM option 'CompileThreshold=100'
 VM option 'MarkSweepAlwaysCompactCount=1'
 VM option 'NmethodSweepFraction=1'


How to reproduce:
    I'll update the bug report as soon as I get a reproduciable case.
Error Log:

[26/Mar/2003:22:18:23] WARNING ( 9755): CORE3283: stderr: # To suppress the following error report, specify this argument
[26/Mar/2003:22:18:23] WARNING ( 9755): CORE3283: stderr: # after -XX: or in .hotspotrc:  SuppressErrorAt=/parseHelper.cpp:186
[26/Mar/2003:22:18:23] WARNING ( 9755): CORE3283: stderr: #
[26/Mar/2003:22:18:23] WARNING ( 9755): CORE3283: stderr: # HotSpot Virtual Machine Error, assertion failure
[26/Mar/2003:22:18:23] WARNING ( 9755): CORE3283: stderr: # Please report this error at
[26/Mar/2003:22:18:23] WARNING ( 9755): CORE3283: stderr: # http://java.sun.com/cgi-bin/bugreport.cgi
[26/Mar/2003:22:18:23] WARNING ( 9755): CORE3283: stderr: #
[26/Mar/2003:22:18:23] WARNING ( 9755): CORE3283: stderr: # Java VM: Java HotSpot(TM) Server VM (20030321101233.robertg.baseline-fastdebug-debug mixed
mode)
[26/Mar/2003:22:18:23] WARNING ( 9755): CORE3283: stderr: #
[26/Mar/2003:22:18:23] WARNING ( 9755): CORE3283: stderr: # assert(will_link, "_new: typeflow responsibility")
[26/Mar/2003:22:18:23] WARNING ( 9755): CORE3283: stderr: #
[26/Mar/2003:22:18:23] WARNING ( 9755): CORE3283: stderr: # Error ID: /net/balvenie.sfbay/export/imgr_home/ws/20030321101233.robertg.baseline/src/share
/vm/opto/parseHelper.cpp, 186 [ Patched ]
[26/Mar/2003:22:18:23] WARNING ( 9755): CORE3283: stderr: #
[26/Mar/2003:22:18:23] WARNING ( 9755): CORE3283: stderr: # Problematic Thread: prio=5 tid=0x002fe7f8 nid=0x14 runnable
[26/Mar/2003:22:18:23] WARNING ( 9755): CORE3283: stderr: #
[26/Mar/2003:22:18:23] WARNING ( 9755): CORE3283: stderr: Heap at VM Abort:
[26/Mar/2003:22:18:23] WARNING ( 9755): CORE3283: stderr: Heap
[26/Mar/2003:22:18:23] WARNING ( 9755): CORE3283: stderr:  def new generation   total 339264K, used 203733K [0xb3c00000, 0xc9150000, 0xc9150000)
[26/Mar/2003:22:18:23] WARNING ( 9755): CORE3283: stderr:   eden space 329024K,  61% used [0xb3c00000, 0xc02f57a8, 0xc7d50000)
[26/Mar/2003:22:18:23] WARNING ( 9755): CORE3283: stderr:   from space 10240K,   0% used [0xc7d50000, 0xc7d50000, 0xc8750000)
[26/Mar/2003:22:18:23] WARNING ( 9755): CORE3283: stderr:   to   space 10240K,   0% used [0xc8750000, 0xc8750000, 0xc9150000)
[26/Mar/2003:22:18:23] WARNING ( 9755): CORE3283: stderr:  tenured generation   total 699072K, used 0K [0xc9150000, 0xf3c00000, 0xf3c00000)
[26/Mar/2003:22:18:23] WARNING ( 9755): CORE3283: stderr:    the space 699072K,   0% used [0xc9150000, 0xc9150000, 0xc9150200, 0xf3c00000)
[26/Mar/2003:22:20:09] SEVERE ( 9754): CORE3107: Child process closed admin channel
Comments
EVALUATION ###@###.### 2003-04-07 Possible that class unloading has occurred during compilation causing the value of will_link (is linked) to change between the initial type flow pass and parsing. ----- I have a couple of theories about what's wrong here, with associated fixes. But I cannot choose between them without some way to reproduce the bug. I am working on smaller test cases to reproduce this assertion. If the bug cannot be reproduced, I suggest downgrading the priority or reassigning it to Tiger. ###@###.### 2003-05-02 This bug is reproduciable only in fastdebug binary with parallelGC. I am still trying to get a reproduciable case. I'll let you know. ###@###.### 2003-05-06 ----- ###@###.### 2003-05-07 The assertion fails because a klass is available early in the compile and then disappears later on. Since the call to ciEnv::get_unloaded_klass forces the CI to treat a klass as unloaded, even if it were previously loaded, I looked at code paths which might cause get_unloaded_klass to execute, even after it had previously been observed by the CI. The method catch_klass() looks suspicious, and it might need repair, but in practice a class always loads its exceptions during verification, so I don't think we can model the present bug as a stumble through catch_klass(). I tried building a test case that causes the assert (by having a loaded exception klass fail to link), but this seems impossible in practice. Once the CI observes a loaded klass, it builds a ciObject for it, which includes a global handle. This means that the klass cannot (all by itself) unload, since the CI is holding a reference to it, keeping it live. Given that this bug reproduces only with ParallelGC, I wonder if this is a parallel GC bug, whereby a klass can be unloaded even though the CI is trying to hold onto a reference to it. We should consider handing this bug over to the GC guys. The linkage to C2 might simply be that C2 runs slowly enough to let the GC drop the klass during the C2 task. ----- I could able to reproduce this bug, And I created a script to run the Ecperf in: cd /net/jano.sfbay/export/disk20/GammaBase/Bugs/4838812 Please read README in the directory ksh doit.ksh ###@###.### 2003-05-07 Is this bug reproducible after the fix to 4827458? If not, I will close it as a dup of 4827458. ###@###.### 2003-11-18
07-05-2003