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.r...@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.rom...@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
