8158913: RFR: aarch64: SEGV running Spark terasort

Edward Nevill edward.nevill at gmail.com
Tue Jun 7 10:26:01 UTC 2016


Please review the following webrev

JIRA issue: https://bugs.openjdk.java.net/browse/JDK-8158913

The problem occurs in gen_write_ref_array_post_barrier in the following code

          __ BIND(L_loop);
          __ strb(zr, Address(start, count));
          __ subs(count, count, 1);
          __ br(Assembler::HS, L_loop);

which, when given a count of 0 will continue zeroing memory beyond the end of the byte map because of the use of unsigned comparison.

Both x86 and Sparc use a signed comparison here.

The webrev above just changes the unsigned comparison to signed to match x86 and sparc.

However, in the case that count is 0 there will will still be one store to the byte map. This is harmless as it just means that it unnecessarily dirties an entry in the byte map (provided that the start address is correct).

Is this the correct fix. Or is it better to fix all of x86, spark, etc so that they do not do any stores when the count is 0?

All the best,

More information about the hotspot-compiler-dev mailing list