Bug: CTW fails compiling java/util/Base64$Encode

[Aleksey Shipilev]

On 1/21/19 7:24 PM, Aleksey Shipilev wrote:
> On 1/21/19 1:37 PM, Roland Westrelin wrote:
>>> CONF=linux-x86_64-server-fastdebug make run-test TEST=applications/ctw/modules/
>>> TEST_VM_OPTS="-XX:+UnlockExperimentalVMOptions -XX:+UseShenandoahGC -XX:-TieredCompilation
>>> -XX:+UnlockDiagnosticVMOptions -XX:+ShenandoahVerifyOptoBarriers"
> 
> Just reproduced again at jdk/jdk with this command (only compile java.base, much shorter):
> 
> $ CONF=linux-x86_64-server-fastdebug make run-test TEST=applications/ctw/modules/java_base.java
> TEST_VM_OPTS="-XX:+UnlockExperimentalVMOptions -XX:+UseShenandoahGC -XX:-TieredCompilation
> -XX:+UnlockDiagnosticVMOptions -XX:+ShenandoahVerifyOptoBarriers"
> 
>> That command runs to completion on my machine. Would you have replay +
>> hs_err files?
> 
> Here:
>   http://cr.openjdk.java.net/~shade/shenandoah/crashes/base64-c2/

I think that is simply because we are missing barriers in new Base64 intrinsics, and you also need a
recent hardware with AVX-512 [1] to actually step on that. Test starts to pass with this patch:
  http://cr.openjdk.java.net/~shade/shenandoah/fix-base64.patch

(Not very sure must_be_not_null is needed; inspecting the Java code shows that intrinsified method
is always called with non-null src/dst)

-Aleksey

[1] https://bugs.openjdk.java.net/browse/JDK-8205528