[9] RFR (S): 8153540: C2 intrinsic for Unsafe.allocateInstance doesn't properly filter out array classes
Vladimir Ivanov
vladimir.x.ivanov at oracle.com
Fri Apr 8 16:47:49 UTC 2016
http://cr.openjdk.java.net/~vlivanov/8153540/webrev.00/hotspot/
http://cr.openjdk.java.net/~vlivanov/8153540/webrev.00/jdk/
https://bugs.openjdk.java.net/browse/JDK-8153540
Unsafe.allocateInstance intrinsic can instantiate arrays, but the
allocation logic is broken.
The proposed fix is to perform necessary checks in Java code before
calling the intrinsic.
I did some performance measurements [1] and reflection (non-constant
class) case (non-constant class) regressed ~5-10% due to new guards added.
I also experimented with a hotspot-only fix [2], but it looks uglier.
So, if you consider the regression in reflective case non-critical, I'd
prefer to go with JDK checks.
Testing: regression test, JPRT, RBT (pit-hs-comp; in progress),
microbenchmarks.
Thanks!
Best regards,
Vladimir Ivanov
[1] http://cr.openjdk.java.net/~vlivanov/8153540/AllocInstance.java
Baseline:
AllocInstance.testConstant avgt 25 3.736 ± 0.054 ns/op
AllocInstance.testReflective avgt 25 5.880 ± 0.080 ns/op
JDK fix:
AllocInstance.testConstant avgt 25 3.959 ± 0.205 ns/op
AllocInstance.testReflective avgt 25 6.274 ± 0.180 ns/op
[2] http://cr.openjdk.java.net/~vlivanov/8153540/webrev.slow_path
AllocInstance.testConstant avgt 25 3.957 ± 0.159 ns/op
AllocInstance.testReflective avgt 25 5.901 ± 0.057 ns/op
More information about the hotspot-compiler-dev
mailing list