Open JDK8 fast-debug : crashes on Solaris Sparc T4 machines
vladimir.kozlov at oracle.com
Thu Feb 13 18:56:40 UTC 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.
On 6/10/10 2:59 PM, John Coomes wrote:
> 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
> 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
> 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 ?
>> 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
>>> 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
>>> V [libjvm.so+0x8f07a8]
>>> 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
>>> V [libjvm.so+0x82daac] void
>>> V [libjvm.so+0x82d7f8] void
>>> V [libjvm.so+0x82c260] void
>>> V [libjvm.so+0x82a82c] void InstanceKlass::initialize(Thread*)+0x5c
>>> V [libjvm.so+0x8dad34] void
>>> j java.lang.System.initializeSystemClass()V+37
>>> v ~StubRoutines::call_stub
>>> V [libjvm.so+0x8fe0bc] void
>>> V [libjvm.so+0x8fd31c] void
>>> V [libjvm.so+0x8fd8bc] void
>>> V [libjvm.so+0xf27f80] void call_initializeSystemClass(Thread*)+0x80
>>> V [libjvm.so+0xf3317c] int
>>> 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
>>> 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 build-dev