RFR: 8265480: add basic JVMCI support for JEP 309: Dynamic Class-File Constants [v3]
psandoz at openjdk.java.net
Wed Apr 21 22:22:20 UTC 2021
On Wed, 21 Apr 2021 20:49:56 GMT, Doug Simon <dnsimon at openjdk.org> wrote:
>> This PR adds support to JVMCI for CONSTANT_Dynamic constant pool entries. It brings the JVMCI support on par with the support in CI for C1 and C2 with one difference: JVMCI will resolve unresolved condy entries where as CI bails out in this case (it expects condy entries to be resolved by the interpreter).
>> When using JVMCI for JIT compilation, unresolved entries should only be seen when running under -Xcomp.
>> When using JVMCI for AoT (e.g. Native Image), most entries will be unresolved since no other code apart from the AoT compiler is running.
> Doug Simon has updated the pull request incrementally with one additional commit since the last revision:
> removed unreachable code
I am not an expert in HS/JVMCI code, but i can mostly follow it. Test looks good. I did wonder if there should be a test for a BSM with a ref type of say `List` rather than `String` given the latter can be represented directly in the constant pool (i don't know if that would exercise different code paths).
Why does a dynamic constant producing a primitive value need to be explicitly processed by `resolvePossiblyCachedConstantInPool`? Is that so specific certain primitive values can be identified and/or values normalized in some manner.
More information about the hotspot-compiler-dev