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

[Vladimir Kozlov]

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.koz...@oracle.com]
Sent: Mittwoch, 12. Februar 2014 21:38
To: Phil Race; Baesken, Matthias; hotspot-...@openjdk.java.net; 
build-dev@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