RFR: JDK-8210031: implementation for JVM Constants API

[Vicente Romero]

Hi all,

Please review also the CSR at [1].

Thanks,
Vicente

[1] https://bugs.openjdk.java.net/browse/JDK-8202031

On 10/15/18 2:12 PM, Vicente Romero wrote:
> 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
>>>
>>
>