PPC64: JVM crash on Hadoop + Terasort

Gustavo Romero gromero at linux.vnet.ibm.com
Wed Dec 7 22:14:35 UTC 2016


Hi,

We are experiencing some JVM crashes on 8 when trying to load
a large Terasort data set (1 TiB) into Hadoop on PPC64.

Please refer to the following hs_err log:
http://paste.fedoraproject.org/501254/48114364/raw/

The crash seems to be due to an indexed doubleword store in
libjvm.so:

0x85aeb4:	2a 49 e8 7e 	stdx    r23,r8,r9

that by its turn is generated from

<CardTableModRefBS::process_stride(Space*, MemRegion, int, int, OopsInGenClosure*, CardTableRS*, signed char**, unsigned long, unsigned long)+468>:	stdx    r23,r8,r9

present in Parallel GC code hotspot/src/share/vm/gc_implementation/parNew/parCardTableModRefBS.cpp

259	  } else {
260	    // In this case we can help our neighbour by just asking them
261	    // to stop at our first card (even though it may not be dirty).
262	    NOISY(tty->print_cr(" LNC: first block is not a non-array object; setting LNC to first card of current chunk");)
263	    assert(lowest_non_clean[cur_chunk_index] == NULL, "Write once : value should be stable hereafter");
264	    jbyte* first_card_of_cur_chunk = byte_for(chunk_mr.start());
265	    lowest_non_clean[cur_chunk_index] = first_card_of_cur_chunk;
266	  }

0x85aeb4: 2a 49 e8 7e stdx r23,r8,r9 is generated from parCardTableModRefBS.cpp:265 more precisely.

I'm not able to reproduce that yet on 9 and create a test case but
I would like to ask if someone know some issue potentially related to that
one and already reported to the JBS. I could not find any recent ones.

Also, what could be a good code or JVM configuration to exercise intensively that code,
i.e. the else branch parCardTableModRefBS.cpp:259-265.

Thank you very much.


Regards,
Gustavo



More information about the hotspot-dev mailing list