RFR: JDK-8210031: implementation for JVM Constants API
Vicente Romero
vicente.romero at oracle.com
Wed Oct 10 16:30:30 UTC 2018
Hi all,
I have updated the webrev [1], this version removes the `implements
Constable` from the symbolic descriptor classes. Feedback is mostly
appreciated,
Thanks,
Vicente
[1] http://cr.openjdk.java.net/~vromero/8210031/webrev.01/jdk12.dev.patch
On 10/06/2018 05:00 PM, Brian Goetz wrote:
> What we decided to do here is to hold back on “implements Constable” for the symbolic descriptor classes in the initial push of JEP-334, and then when we have the symbolic expression mode for BSMs, re-implement those in XxxDesc using that. Implementing Constable isn’t needed until we get to the full constant folding anyway. That linearizes the dependencies — first JEP-334, then symbolic mode BSM, then update JEP-334 classes to implement Constable using symbolic mode BSM.
>
>> On Sep 13, 2018, at 9:07 PM, John Rose <john.r.rose at oracle.com> wrote:
>>
>> I am running a review of VM-level work on bootstrap methods
>> which can optionally help simplify some of these APIs:
>>
>> http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2018-September/030084.html
>>
>> Specifically, this work can be use to implement a "symbolic
>> expression mode" for BSMs which causes the JVM to unpack
>> constant pool nodes directly as ConstantDesc items to present
>> to BSMs. This might simplify the condy forms of ConstantDesc
>> instances, if javac stores native constants to reflect, rather than
>> lists of strings to reassemble.
>>
>> — John
>>
>> On Sep 11, 2018, at 12:50 PM, Vicente Romero <vicente.romero at oracle.com> wrote:
>>> Please review the first iteration of the implementation for JEP-334 [1] JVM Constants API. The implementation can be found at [2]. JEP-334 introduces an API to model nominal descriptions of key class-file and run-time artifacts, in particular constants that are loadable from the constant pool and has already been the subject of several discussions. The implementation of this JEP has been publicly accessible throw the amber repo at [3] in the jep-334 branch. Thanks to all members of the Amber project and specially to Brian for all the hard work on the design and the implementation of this API. Thanks for all the feedback we have received so far, most of it has been integrated in the current implementation.
>>>
>>> Thanks,
>>> Vicente
>>>
>>> [1] http://openjdk.java.net/jeps/334
>>> [2] http://cr.openjdk.java.net/~vromero/8210031/webrev.00/jdk.dev.patch
>>> [3] http://hg.openjdk.java.net/amber/amber
More information about the compiler-dev
mailing list