There is a JMH micro in the JDK repo:

org.openjdk.bench.java.util.ArraysFill

C2 uses a vectorized vmovdqu sequence to fill the buffer but Graal is using 1 byte stores in the byte case:

 14.24% \u2502\u2502\u2197 \u2502 0x00007fbfb5b0cd00: cmp %ecx,%r9d
         \u2502\u2502\u2502 \u2502 0x00007fbfb5b0cd03: jbe 0x00007fbfb5b0cda5
 21.97% \u2502\u2502\u2502 \u2502 0x00007fbfb5b0cd09: movb $0xff,0x10(%rcx,%r8,8) ;*bastore {reexecute=0 rethrow=0 return_oop=0}
         \u2502\u2502\u2502 \u2502 ; - java.util.Arrays::fill@13 (line 3286)
         \u2502\u2502\u2502 \u2502 ; - org.openjdk.bench.java.util.ArraysFill::testByteFill@5 (line 78)
         \u2502\u2502\u2502 \u2502 ; - org.openjdk.bench.java.util.generated.ArraysFill_testByteFill_jmhTest::testByteFill_avgt_jmhStub@15 (line 186)

This is the root cause of the regression in other open CR's
https://bugs.openjdk.java.net/browse/JDK-8213319
https://bugs.openjdk.java.net/browse/JDK-8213396
https://bugs.openjdk.java.net/browse/JDK-8237401