-
Enhancement
-
Resolution: Fixed
-
P4
-
None
-
b23
While Unsafe::allocateInstance is intrinsified by C2, it's somewhat costly when used from interpreter and C1 compiled code - ~100ns/op overhead compared to the C2 intrinsic for trivial calls.
This was made apparent when looking into some regressions in startup of capturing lambdas that coming in from the hidden classes JEP, see: https://mail.openjdk.java.net/pipermail/core-libs-dev/2020-May/066270.html
Investigating it seems the call chain in unsafe.cpp could be simplified. This gets the cost in the capturing lambda microbenchmark down from ~105ns/op to ~65ns/op for C1 code (same 40ns/op gain for interpreter calls). Likely helps other places during startup too, so seems worth doing.
This was made apparent when looking into some regressions in startup of capturing lambdas that coming in from the hidden classes JEP, see: https://mail.openjdk.java.net/pipermail/core-libs-dev/2020-May/066270.html
Investigating it seems the call chain in unsafe.cpp could be simplified. This gets the cost in the capturing lambda microbenchmark down from ~105ns/op to ~65ns/op for C1 code (same 40ns/op gain for interpreter calls). Likely helps other places during startup too, so seems worth doing.
- relates to
-
JDK-8244606 Non-PCH build is broken after JDK-8244550
-
- Resolved
-
-
JDK-8244625 Zero VM is broken after JDK-8244550 (java_lang_Class::as_Klass(oopDesc*) undefined)
-
- Resolved
-