The array fill optimization [1] replaces simple array initialization loops with calls to array-fill intrinsics. For arrays of shorts, the optimization wrongly assigns the address type char[] to its resulting array fill intrinsic call, instead of the expected type short[] [2]. As a consequence, anti-dependence analysis [3] fails to recognize and enforce anti-dependences between short[] loads and the intrinsic call. This can cause GCM/LCM to schedule such loads too late, triggering a miscompilation. Besides missing anti-dependences, there might be other unanticipated failures due to type mismatches.

The attached example illustrates the issue:

$ java -ea -Xint Test.java

$ java -ea -Xbatch -XX:-TieredCompilation -XX:CompileOnly=Test::test -XX:LoopUnrollLimit=0 -XX:+OptimizeFill Test.java
Exception in thread "main" java.lang.AssertionError
at Test.main(Test.java:39)

cfg.pdf (attached) shows the control-flow graph of Test::test() after C2's scheduling phase. Note how the load (160 loadS) is wrongly scheduled after the intrinsic call (142 CallLeafNoFPDirect). Anti-dependency analysis misses their anti-dependency because of their different alias indices 10 and 7 (derived from their address types char[] and short[]).

[1] https://github.com/openjdk/jdk/blob/4e1367e34be724a0f84069100854c38333610714/src/hotspot/share/opto/loopTransform.cpp#L3772
[2] https://github.com/openjdk/jdk/blob/4e1367e34be724a0f84069100854c38333610714/src/hotspot/share/opto/memnode.hpp#L680
[3] https://github.com/openjdk/jdk/blob/4e1367e34be724a0f84069100854c38333610714/src/hotspot/share/opto/gcm.cpp#L681