Open JDK8 fast-debug : crashes on Solaris Sparc T4 machines

Thu Feb 13 12:02:46 UTC 2014

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 SunOS_sparc 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 :
>>
>>
>>    <maindir>/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/open_jdk/jdk8_2/hotspot/src/share/vm/prims/jni.cpp:278),
>> pid=27252, tid=2
>> #  guarantee(klass_hash_ok(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:
>> # //hs_err_pid27252.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 hs_err file  :
>>
>> ---------------  T H R E A D  ---------------
>>
>> Current thread (0x0000000100111800):  JavaThread "main"
>> [_thread_in_vm, 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::report_and_die()+0x504
>> V  [libjvm.so+0x66ee70]  void report_vm_error(const char*,int,const
>> char*,const char*)+0x78
>> V  [libjvm.so+0x925798]  void
>> jfieldIDWorkaround::verify_instance_jfieldID(Klass*,_jfieldID*)+0xa8
>> V  [libjvm.so+0x8f07a8]
>> _jfieldID*jfieldIDWorkaround::to_instance_jfieldID(Klass*,int)+0x60
>> V  [libjvm.so+0x953b8c]  jni_GetFieldID+0x52c
>> C  [libjava.so+0xe46c]  Java_java_io_FileInputStream_initIDs+0x44
>> j  java.io.FileInputStream.initIDs()V+-373565320
>> j  java.io.FileInputStream.initIDs()V+0
>> j  java.io.FileInputStream.<clinit>()V+0
>> v  ~StubRoutines::call_stub
>> V  [libjvm.so+0x8fe0bc]  void
>> JavaCalls::call_helper(JavaValue*,methodHandle*,JavaCallArguments*,Thread*)+0x4e4
>>
>> V  [libjvm.so+0x82daac]  void
>> InstanceKlass::call_class_initializer_impl(instanceKlassHandle,Thread*)+0x224
>>
>> V  [libjvm.so+0x82d7f8]  void
>> InstanceKlass::call_class_initializer(Thread*)+0x24
>> V  [libjvm.so+0x82c260]  void
>> InstanceKlass::initialize_impl(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::call_stub
>> V  [libjvm.so+0x8fe0bc]  void
>> JavaCalls::call_helper(JavaValue*,methodHandle*,JavaCallArguments*,Thread*)+0x4e4
>>
>> V  [libjvm.so+0x8fd31c]  void
>> JavaCalls::call_static(JavaValue*,KlassHandle,Symbol*,Symbol*,JavaCallArguments*,Thread*)+0x104
>>
>> V  [libjvm.so+0x8fd8bc]  void
>> JavaCalls::call_static(JavaValue*,KlassHandle,Symbol*,Symbol*,Thread*)+0x64
>>
>> V  [libjvm.so+0xf27f80]  void call_initializeSystemClass(Thread*)+0x80
>> V  [libjvm.so+0xf3317c]  int
>> Threads::create_vm(JavaVMInitArgs*,bool*)+0x76c
>> V  [libjvm.so+0x9772ec]  JNI_CreateJavaVM+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 :
>>
>>    <maindir>/results/SS12u1/images/j2sdk-image/bin/java -version
>> openjdk version "1.8.0-internal-fastdebug"
>> OpenJDK Runtime Environment (build
>> 1.8.0-internal-fastdebug-d040975_2014_02_12_15_29-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
>