One of our partners has reported SEGV running Spark Terasort.

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.

Here is the partners report

"
    I find that in certain cases StubRoutines::_generic_arraycopy can be passed an element count of zero.
    And this zero element count may be further passed to StubRoutines::_arrayof_oop_disjoint_arraycopy.
    In that case, it will trigger a segmentation fault in native code generated by gen_write_ref_array_post_barrier.
    The reason is that we got a zero count before entering the following loop, but we are using unsigned compare here to check the loop condition.
    710 __ BIND(L_loop);
    711 __ strb(zr, Address(start, count));
    712 __ subs(count, count, 1);
    713 __ br(Assembler::HS, L_loop);
    714 }

    I checked X86 and Sparc port, they both use signed compare with zero here.

    Patch was generated from the the latest jdk9 hs-comp repo:

diff -r 7f42e988b083 src/cpu/aarch64/vm/stubGenerator_aarch64.cpp
--- a/src/cpu/aarch64/vm/stubGenerator_aarch64.cpp Thu Jun 02 17:52:42 2016 +0000
+++ b/src/cpu/aarch64/vm/stubGenerator_aarch64.cpp Mon Jun 06 13:51:51 2016 +0800
@@ -710,7 +710,7 @@
           __ BIND(L_loop);
           __ strb(zr, Address(start, count));
           __ subs(count, count, 1);
- __ br(Assembler::HS, L_loop);
+ __ br(Assembler::GE, L_loop);
         }
         break;
       default:
"