JDK-4971124 : JIT Compiler crashes c2/opto/server VM on 1.4.2 ( Windows + Solaris )
  • Type: Bug
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: 1.4.2_03
  • Priority: P1
  • Status: Resolved
  • Resolution: Fixed
  • OS: generic
  • CPU: generic
  • Submitted: 2003-12-19
  • Updated: 2004-03-30
  • Resolved: 2004-03-08
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.
Other
1.4.2_05 05Fixed
Related Reports
Relates :  
JDK-4985384 - Java 1.4.2_03 C2 Compiler Crash with SIGBUS on Solaris
Relates :  
JDK-4911268 - CTW assertion at type.hpp, 349
Description
C2 Compiler crashes in method: addIviewResource in attached source code.

There are additional known methods which lead to the crashes;
They are documented in SAP internal note 693169.

exclude com/sap.mw/jco/util/SAPCharToNUCByteConverter outLength
exclude com/sapportals/portal/pb/layout/taglib/ContainerTag addIviewResource
exclude com/sap/engine/services/keystore/impl/security/CodeBasedSecurityConnector  
	getApplicationDomain

Another way to avoid the crashes is the option -XX:-Inline

All crashes are platform independent the happen on Solaris,Windows and Linux
(32 Bit and 64 Bit).


###@###.### 2004-01-12
Comments
CONVERTED DATA BugTraq+ Release Management Values COMMIT TO FIX: 1.4.2_05 generic tiger-beta2 FIXED IN: 1.4.2_05 tiger-beta2 INTEGRATED IN: 1.4.2_05 tiger-b42 tiger-beta2
14-06-2004
SUGGESTED FIX See: http://analemma.sfbay.sun.com/net/prt-archiver.sfbay/export2/archived_workspaces/main/c2_baseline/2004/20040302070650.rasbold.c2_baseline/workspace/webrevs/webrev-2004.03.02/index.html ###@###.### 2004-03-02
02-03-2004
EVALUATION The details on this bug are very sketchy. Answers to some of these questions would help us get started: Does the crash happen every time in the application? How soon does it happen after application startup? What does the stack trace look like on failure? Do you have a test case that we can reproduce? A small test case? Can we have the .class or .jar file(s)? Will you run alternate VMs for us? Does it happen with -XX:-Inline? What does the -XX:+PrintCompilation -XX:-CICompilerCount=1 output look like? ###@###.### 2003-12-22 With fastdebug, the application asserts on src/share/vm/opto/type.hpp, 326, same as 4911268. Yumin has backported the fix for 4911268 to 1.4.2 and reran the SAP application under fastdebug without problem. ###@###.### 2004-01-14 Further investigation shows an assert in do_exits() indicating a unexpected condition upon exit. We are seeing multiple ciKlass objects in this compilation for the class java.servlet.http.Cookie, all but one of which are marked as "unloaded". We believe that the conflict between the "loaded" ciKlass object and the others is the cause of the problems in the compiler. The use of multiple class loaders in the application may be triggering the CI problem. We are instrumenting the CI to find out more information. ###@###.### 2004-01-28 A combination of multiple class loaders and inlining is causing the problem. A class is resolved during inlining, triggering a switch from "unloaded" to "loaded" of the return ciKlass. The compiler senses the conflict in types at the return Phi merge point, and thinks the return is unreachable. First, the easy fix is to use TypeOopPtr::Bottom for the ret_phi when the compiler sees an unloaded type. A better choice would be to delay the creation of the return type (C2-wise) until the complete method has been parsed. In this way, the compiler would avoid seeing any unloaded ciKlasses until all resolution is complete. A third change, which would complement either of the first two, would be enforce consistent results from the CI: when loading a klass by name, the CI should check the unloaded klass list to see if any loaded klass with a particular name has already been returned as unloaded. ###@###.### 2004-02-12
12-02-2004