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