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
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?
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.
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.
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.