Bug: ZGC crashes with AbstractMethodError

[Per Liden]

Thanks for reporting! Are you by any chance running on a recent AMD 
machine? We know about a C2 bug only provoked on those CPUs. Nils is 
working on a patch for that.

/Per

On 2017-12-11 10:35, Aleksey Shipilev wrote:
> Hi,
>
> One of our tests (sorry, we can't share it, alas :() fails with weird ZGC crash. Running without JMH
> forking -- because I suspected the bug is triggered by serialization in host-forked VM link --
> reveals AbstractMethodError:
>
> # Detecting actual CPU count: 16 detected
> # JMH version: 1.19
> # VM version: JDK 10-internal, VM 10-internal+0-adhoc.shade.zgc-zgc
> # VM invoker: /home/shade/trunks/zgc-zgc/build/baseline/bin/java
> # VM options: -Xmx8g -Xms8g -XX:+AlwaysPreTouch -XX:+UseZGC
> # Warmup: 5 iterations, 1 s each
> # Measurement: 5 iterations, 10 s each
> # Timeout: 10 min per iteration
> # Threads: 16 threads, will synchronize iterations
> # Benchmark mode: Throughput, ops/time
> # Benchmark: ...
>
> # Run progress: 0.00% complete, ETA 00:00:55
> # Fork: N/A, test runs in the host VM
> # *** WARNING: Non-forked runs may silently omit JVM options, mess up profilers, disable compiler
> hints, etc. ***
> # *** WARNING: Use non-forked runs only for debugging purposes, not for actual performance runs. ***
> # Warmup Iteration   1: <failure>
>
> Exception in thread "main" java.lang.AbstractMethodError:
> java.lang.Throwable.printStackTrace(Ljava/io/PrintWriter;)V
> 	at org.openjdk.jmh.util.Utils.throwableToString(Utils.java:162)
> 	at org.openjdk.jmh.runner.BaseRunner.doSingle(BaseRunner.java:150)
> 	at org.openjdk.jmh.runner.BaseRunner.runBenchmarksEmbedded(BaseRunner.java:111)
> 	at org.openjdk.jmh.runner.Runner.runBenchmarks(Runner.java:550)
> 	at org.openjdk.jmh.runner.Runner.internalRun(Runner.java:313)
> 	at org.openjdk.jmh.runner.Runner.run(Runner.java:206)
> 	at org.openjdk.jmh.Main.main(Main.java:71)
>
>
> This does not happen with UseSerialGC. This does not happen with -XX:TieredStopAtLevel=1. This does
> not happen with -Xint. What's more frustrating, the issue is only reproducible with release bits,
> not with fastdebug.
>
> It seems as if something gone awry with C2? Do you have a hunch what that might be? And, how to
> diagnose this better?
>
> Workload does lots of floating pointing math (which probably means XMM/YMM usage), that might be a clue.
>
> Thanks,
> -Aleksey
>