Fatal Error on PPC64 and PPC64LE for both JDK7 and JDK8

Sat Apr 18 06:22:40 UTC 2015

On Fri, Apr 17, 2015 at 9:42 PM, Tiago Sturmer Daitx
<tdaitx at linux.vnet.ibm.com> wrote:
> Goetz,
>
> You are right, it seems RHEL 7.1 JDK 8 is using the C++ interpreter:
>
> $ /usr/lib/jvm/java-1.8.0-openjdk/bin/java -XX:
> +UnlockDiagnosticVMOptions -XX:+PrintInterpreter -version
> ----------------------------------------------------------------------
> Interpreter
>
> code size        =      5K bytes
> total space      =     11K bytes
> wasted space     =      6K bytes
>
> # of codelets    =      3
> avg codelet size =   2005 bytes
>
>
> ----------------------------------------------------------------------
> slow signature handler  [0x00003fff98005f80, 0x00003fff98006400]  1152
> bytes
>
> Could not load hsdis-ppc64le.so; library not loadable; PrintAssembly is
> disabled
>
> ----------------------------------------------------------------------
> result handlers for native calls  [0x00003fff98006480,
> 0x00003fff98006680]  512 bytes
>
>
> ----------------------------------------------------------------------
> (kind = frame_manager)  [0x00003fff98006700, 0x00003fff98007680]  3968
> bytes
>
> ----------------------------------------------------------------------
>
> openjdk version "1.8.0_45"
> OpenJDK Runtime Environment (build 1.8.0_45-b13)
> OpenJDK 64-Bit Server VM (build 25.45-b02, mixed mode)
>
>
> Running the same flags against RHEL 7.1 JDK 7 or the custom build jdk7u
> shows a muuuuch bigger output, which I assume to be the template.
>
> Anyway, would you still be able to help with the JDK 7? That one is
> running the Template as far as I can tell.
>
> Meanwhile I will take a look at source RPM for JDK8 and check what they
> are doing there.
>
> I'm curious: why would the C++ interpreter still be enabled/available if
> it is not maintained?
>

The decision template vs. c++ interpreter is a build time decision
(--with-jvm-interpreter=template|cpp with 'template' being the
default). It's probably this configure option which is still lurking
around in the build scripts of some of the Linux distros and which we
strongly recommend to remove for Linux/ppc64.

Regards,
Volker

> Regards,
> Tiago
>
> On Fri, 2015-04-17 at 13:49 +0000, Lindenmaier, Goetz wrote:
>> Hi Tiago,
>>
>> from the hs_err-pid24587-1.8.0.45.log it looks like you are using the bytecode interpreter (C++ interpreter).
>> Why that?
>> Is this the case for all the VMs you tested?
>> I can’t tell whether the bug is related to that, but we didn’t test it
>> for about a year now.
>> Could you please try to reproduce the problem with the template interpreter?
>> That would be great!
>>
>> Best regards,
>>   Goetz.
>>
>> -----Original Message-----
>> From: Tiago Sturmer Daitx [mailto:tdaitx at linux.vnet.ibm.com]
>> Sent: Freitag, 17. April 2015 15:17
>> To: Lindenmaier, Goetz
>> Subject: Re: Fatal Error on PPC64 and PPC64LE for both JDK7 and JDK8
>>
>> Goetz,
>>
>> Thanks for your help!
>>
>> I have attached a zip file containing a few hs_err reports. They have:
>> - the pid number, in case you want additional debugging information,
>> just refer to it
>> - which of the 3 JVMs was used to generate them, between RHEL 7.1
>> OpenJDK 7 and 8 and a custom jdk7u build from ppc-aix-port repo
>>
>> You will see 2 files for each jvm above, they come from 2 components:
>> oozie/core and oozie/sharedlib/pig.
>>
>> I do have more if those are not enough.
>>
>> If at all possible (I completely understand if you are unable to), I
>> would really appreciate if you could share what kind of information you
>> were able to find and how (no need to be very detailed, just enough so I
>> can take a peek and try to understand it myself). I tried to get some
>> information out of the hs_err files but didn't amount to much, that's
>> why I decided to install the debug symbols and poke around.
>>
>> Regards,
>> Tiago
>>
>> On Fri, 2015-04-17 at 10:03 +0000, Lindenmaier, Goetz wrote:
>> > Hi Tiago
>> >
>> >
>> >
>> > Can you send us the full hs_err file?   What’s the Java args?
>> >
>> >
>> >
>> > Best regards,
>> >
>> >   Goetz.
>> >
>> >
>> >
>> > PS: I included your power 8 recognition in a larger change I
>> >
>> > want to submit into the ppc directory.  Will come right after
>> >
>> > my change to adlc was pushed, which is a prerequisite.
>> >
>> >
>> >
>> > From: ppc-aix-port-dev
>> > [mailto:ppc-aix-port-dev-bounces at openjdk.java.net] On Behalf Of Tiago
>> > Sturmer Daitx
>> > Sent: Freitag, 17. April 2015 01:07
>> > To: ppc-aix-port-dev at openjdk.java.net
>> > Subject: Re: Fatal Error on PPC64 and PPC64LE for both JDK7 and JDK8
>> >
>> >
>> >
>> >
>> > On Thu, 2015-04-16 at 20:00 -0300, Tiago Sturmer Daitx wrote:
>> >
>> >
>> >
>> >
>> > JDK7u from PPC-AIX-Port repository
>> > ----------------------------------------------
>> >
>> >
>> > $ grep -e "Core dump" -e "hs_error" oozie-ppc-aix-port.stdout
>> > # Core dump written. Default location: /home/tdaitx/oozie/client/target/site/apidocs/core or core.26317
>> > # Core dump written. Default location: /home/tdaitx/oozie/core/core or core.29406
>> > # Core dump written. Default location: /home/tdaitx/oozie/sharelib/pig/core or core.30071
>> > # Core dump written. Default location: /home/tdaitx/oozie/sharelib/hive/core or core.30108
>> >
>> >
>> >
>> > Sorry, I failed earlier to include a hs_err file just as example for
>> > the custom ppc-aix-port jdk7u build.
>> >
>> >
>> > # A fatal error has been detected by the Java Runtime Environment:
>> > #
>> > #  Internal Error (/home/tdaitx/ppc-aix-port-jdk7u/hotspot/src/share/vm/gc_implementation/parallelScavenge/parMarkBitMap.cpp:263), pid=30108, tid=70365572231632
>> > #  assert(*p == 0) failed: bitmap not clear
>> > #
>> > # JRE version: OpenJDK Runtime Environment (7.0) (build 1.7.0-internal-fastdebug-tdaitx_2015_04_16_17_13-b00)
>> > # Java VM: OpenJDK 64-Bit Server VM (24.75-b04-fastdebug mixed mode linux-ppc64 compressed oops)
>> > # Core dump written. Default location: /home/tdaitx/oozie/sharelib/hive/core or core.30108
>> > #
>> > # If you would like to submit a bug report, please visit:
>> > #   http://bugreport.sun.com/bugreport/crash.jsp
>> > #
>> >
>> > ---------------  T H R E A D  ---------------
>> >
>> > Current thread (0x00003fff88341000):  VMThread [stack: 0x00003fff42d00000,0x00003fff42f00000] [id=30123]
>> >
>> > Stack: [0x00003fff42d00000,0x00003fff42f00000],  sp=0x00003fff42efda00,  free space=2038k
>> > Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
>> > V  [libjvm.so+0xe55120]  VMError::report_and_die()+0x240
>> > V  [libjvm.so+0x548ef4]  report_vm_error(char const*, int, char const*, char const*)+0xb4
>> > V  [libjvm.so+0xbb7bbc]  ParMarkBitMap::verify_clear() const+0x8c
>> > V  [libjvm.so+0xc4c930]  PSParallelCompact::pre_compact(PreGCValues*)+0x290
>> > V  [libjvm.so+0xc5b668]  PSParallelCompact::invoke_no_policy(bool)+0x258
>> > V  [libjvm.so+0xc6c444]  PSScavenge::invoke()+0x434
>> > V  [libjvm.so+0xbc8d58]  ParallelScavengeHeap::failed_mem_allocate(unsigned long)+0x1a8
>> > V  [libjvm.so+0xe581b4]  VM_ParallelGCFailedAllocation::doit()+0x174
>> > V  [libjvm.so+0xe7fb78]  VM_Operation::evaluate()+0xb8
>> > V  [libjvm.so+0xe7ca10]  VMThread::evaluate_operation(VM_Operation*)+0x410
>> > V  [libjvm.so+0xe7d6fc]  VMThread::loop()+0x6bc
>> > V  [libjvm.so+0xe7d9d4]  VMThread::run()+0xf4
>> > V  [libjvm.so+0xb801b0]  java_start(Thread*)+0x170
>> > C  [libpthread.so.0+0x8944]  start_thread+0xf4
>> >
>> > VM_Operation (0x00003ffd3b9f8440): ParallelGCFailedAllocation, mode: safepoint, requested by thread 0x00003fff11cba800
>> >
>> >
>> >
>> >
>>
>
>