Open JDK8 fast-debug : crashes on Solaris Sparc T4 machines (original) (raw)

Vladimir Kozlov vladimir.kozlov at oracle.com
Thu Feb 13 10:56:40 PST 2014

I don't think there is any public info about that. Back in 2010 when we switched to new compilers (Visual Studio, gcc and SunStudio) during jdk7 development we wanted to use SS12 first. But it did not work for us. Below is our internal mail which listed the problem. As result we have to use 12u1 and patches. I can't find the reasoning for patches, they could be recommended by SunStudio group.

Regards, Vladimir

On 6/10/10 2:59 PM, John Coomes wrote:

Hi,

Starting a new thread on this old topic.

We (hotspot) need to get the solaris jdk7 tools updated. We now have a second pain point because of bug(s) in the current ss12 optimizer:

6950537 G1+COOPS: gcbasher crashes during evacuation failure

This is a crash caused by incorrect optimization. The initial pain point has so far prevented the fix for

6423256 GC stacks should use a better data structure

from being integrated into jdk7. This bug was escalated and fixed in a jdk6 update, so is required in jdk7 to prevent regressions.

In both cases, compiling with ss12u1 + patches avoids the problem, and so does compiling with ss11 (so jdk6 updates are not affected).

On 2/13/14 4:02 AM, Baesken, Matthias wrote:

Hi Vladimir / Phil , thank you for the answers . I'm aware of the README-builds.html.

But it states also (besides of telling about using SunStudio 12u1) " The Oracle Solaris Studio Express compilers at: Oracle Solaris Studio Express Download site are also an option, although these compilers have not been extensively used yet." (and there is also still the old SunStudio 12 on the site ) So I wanted to give it a try (and configure works with it too pretty good). > > need compiler fixes, so does the same occur if you upgrade and patch ? > As stated in my original posting, with 12u1 +patches it works nicely , and I understand that you don't want to waste much time with older compilers. But Studio 12 is still interesting for us too (at least HS build part) .

> When we updated to 12u1 we found few problems, that is why patches are > also required. Is there some public info about these problems and relation to the patches in the README ? Regards, Matthias

-----Original Message----- From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com] Sent: Mittwoch, 12. Februar 2014 21:38 To: Phil Race; Baesken, Matthias; hotspot-dev at openjdk.java.net; build-dev at openjdk.java.net Subject: Re: Open JDK8 fast-debug : crashes on Solaris Sparc T4 machines Matthias, You have to use the official version 12u1+patches to build jdk8 Hotspot for solaris. Thank you Phil for pointer to README-builds.html. When we updated to 12u1 we found few problems, that is why patches are also required. The compiler version string we use is: $ CC -V CC: Sun C++ 5.10 SunOSsparc 128228-09 2010/06/24 Regards, Vladimir On 2/12/14 10:32 AM, Phil Race wrote: The README-builds.html file specifies SS12 Update 1 + a bunch of patches There's probably a good reason for all of that and new architectures often need compiler fixes, so does the same occur if you upgrade and patch ? -phil. On 2/12/2014 7:48 AM, Baesken, Matthias wrote: I noticed when building Open JDK 8 fast-debug with Sun Studio 12 on Solaris Sparc, the VM crashes early when executed on T4 based machines (both T4 based Solaris Sparc10 and 11 machines); I cannot see the issue on older Sparc processors or Fujitsu SPARC64. The Crashes look like this :

/results/SS12/images/j2sdk-image/bin/java -version # To suppress the following error report, specify this argument # after -XX: or in .hotspotrc: SuppressErrorAt=/jni.cpp:278 # # A fatal error has been detected by the Java Runtime Environment: # # Internal Error (/net/usr.work/d040975/openjdk/jdk82/hotspot/src/share/vm/prims/jni.cpp:278), pid=27252, tid=2 # guarantee(klasshashok(k, id)) failed: Bug in native code: jfieldID class must match object # # JRE version: (8.0) (build ) # Java VM: OpenJDK 64-Bit Server VM (25.0-b69-fastdebug mixed mode solaris-sparc compressed oops) # Core dump written. Default location: //core or core.27252 # # An error report file with more information is saved as: # //hserrpid27252.log # # If you would like to submit a bug report, please visit: # http://bugreport.sun.com/bugreport/crash.jsp # Current thread is 2 Dumping core ... Abort (core dumped) With Stack in the hserr file : --------------- T H R E A D --------------- Current thread (0x0000000100111800): JavaThread "main" [threadinvm, id=2, stack(0xffffffff7e200000,0xffffffff7e300000)] Stack: [0xffffffff7e200000,0xffffffff7e300000], sp=0xffffffff7e2fdd50, free space=1015k Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) V [libjvm.so+0xfc8824] void VMError::reportanddie()+0x504 V [libjvm.so+0x66ee70] void reportvmerror(const char*,int,const char*,const char*)+0x78 V [libjvm.so+0x925798] void jfieldIDWorkaround::verifyinstancejfieldID(Klass*,jfieldID*)+0xa8 V [libjvm.so+0x8f07a8] jfieldIDjfieldIDWorkaround::toinstancejfieldID(Klass,int)+0x60 V [libjvm.so+0x953b8c] jniGetFieldID+0x52c C [libjava.so+0xe46c] JavajavaioFileInputStreaminitIDs+0x44 j java.io.FileInputStream.initIDs()V+-373565320 j java.io.FileInputStream.initIDs()V+0 j java.io.FileInputStream.()V+0 v ~StubRoutines::callstub V [libjvm.so+0x8fe0bc] void JavaCalls::callhelper(JavaValue*,methodHandle*,JavaCallArguments*,Thread*)+0x4e4 V [libjvm.so+0x82daac] void InstanceKlass::callclassinitializerimpl(instanceKlassHandle,Thread*)+0x224 V [libjvm.so+0x82d7f8] void InstanceKlass::callclassinitializer(Thread*)+0x24 V [libjvm.so+0x82c260] void InstanceKlass::initializeimpl(instanceKlassHandle,Thread*)+0xb08 V [libjvm.so+0x82a82c] void InstanceKlass::initialize(Thread*)+0x5c V [libjvm.so+0x8dad34] void InterpreterRuntime::new(JavaThread*,ConstantPool*,int)+0x254 j java.lang.System.initializeSystemClass()V+37 v ~StubRoutines::callstub V [libjvm.so+0x8fe0bc] void JavaCalls::callhelper(JavaValue*,methodHandle*,JavaCallArguments*,Thread*)+0x4e4 V [libjvm.so+0x8fd31c] void JavaCalls::callstatic(JavaValue*,KlassHandle,Symbol*,Symbol*,JavaCallArguments*,Thread*)+0x104 V [libjvm.so+0x8fd8bc] void JavaCalls::callstatic(JavaValue*,KlassHandle,Symbol*,Symbol*,Thread*)+0x64 V [libjvm.so+0xf27f80] void callinitializeSystemClass(Thread*)+0x80 V [libjvm.so+0xf3317c] int Threads::createvm(JavaVMInitArgs*,bool*)+0x76c V [libjvm.so+0x9772ec] JNICreateJavaVM+0xe4 C [libjli.so+0x7d9c] InitializeJVM+0x104 C [libjli.so+0x6220] JavaMain+0x68

When building with Sun Studio 12u1 (instead of 12) the crash does not occur, see : /results/SS12u1/images/j2sdk-image/bin/java -version openjdk version "1.8.0-internal-fastdebug" OpenJDK Runtime Environment (build 1.8.0-internal-fastdebug-d040975201402121529-b00) OpenJDK 64-Bit Server VM (build 25.0-b69-fastdebug, mixed mode) Is this a known issue with SunStudio12 build results on T4 Processors ? I changed the used optimization flags in the fast-debug build from -xO4 to -xO2 and the problem disappeared. Could this be done in the configuration when SunStudio 12 is detected ? Thanks, Matthias

More information about the hotspot-dev mailing list