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

[Aleksey Shipilev]

On 1/21/19 11:08 PM, Aleksey Shipilev wrote:
> 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)

Filed:
  https://bugs.openjdk.java.net/browse/JDK-8217467

-Aleksey