RFR: JDK-8210031: implementation for JVM Constants API

[Vicente Romero]

Hi all,

sorry for the repeated number of mails on this issue. I have added a 
direct link to the patch the right link to the webrev is [1] there is a 
previous version at [2] if you want to see the differences with the last 
version. Basically we have dropped the `implements Constable` for the 
symbolic descriptor classes and removed all of the code that was useful 
for constant folding but not strictly necessary for the API. For more 
information on the JEP see [3]

[1] http://cr.openjdk.java.net/~vromero/8210031/webrev.01
[2] http://cr.openjdk.java.net/~vromero/8210031/webrev.00
[3] http://openjdk.java.net/jeps/334

On 10/15/2018 01:51 PM, Vicente Romero wrote:
> adding core-libs in the loop
>
> On 10/10/2018 12:30 PM, Vicente Romero wrote:
>> 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
>>
>