Isolated Methods JEP
Michael Haupt
michael.haupt at oracle.com
Fri Aug 12 21:56:14 UTC 2016
Hi Mark,
> Am 05.08.2016 um 12:13 schrieb Mark Roos <mroos at roos.com>:
> Good to see this.
thanks. :-)
> What is the philosophy for code annotations, line numbers and stack maps?
>
> Would they be some form of constant entry?
I recall you had asked this question at JVMLS. I think it definitely makes sense to add support for these. How would you think they should be represented?
Here are some thoughts.
First, stack maps. Leave their generation to the bytecode generation framework responsible for producing the bytecode array (whichever one that may be), allow for easy extraction of the map from its generation result, and for passing that on to the loadCode implementation. This will require a library-level representation of stack maps (inspired by Sec. 4.7.4 of the JVM Spec), unless the plain class file format for them is used - which may not be desirable given the convenience attempts the API is making with the constants array. To maintain convenience, stack map generation could be the responsibility of the loadCode implementation. This would duplicate the work of generating the map, which seems rather unwelcome.
Annotations can be passed as a map from annotation classes to lists of values. Line numbers can be passed as an int array of pairs of numbers, where even indices represent start PCs, and odd indices, line numbers.
Adding to your list, a source file association can be represented as a URL or String. (Cream on top: a multiline String containing the IM's actual source code.) As a further addition, exceptions can be passed as a simple array or list, and an exception handler table can be passed as a tuple (not in the Valhalla sense, yet) of an int array of triplets of numbers representing start, end, and handler PCs and of a list or array of exception classes.
Best,
Michael
--
<http://www.oracle.com/>
Dr. Michael Haupt | Principal Member of Technical Staff
Phone: +49 331 200 7277 | Fax: +49 331 200 7561
Oracle Java Platform Group | LangTools Team | Nashorn
Oracle Deutschland B.V. & Co. KG | Schiffbauergasse 14 | 14467 Potsdam, Germany
ORACLE Deutschland B.V. & Co. KG | Hauptverwaltung: Riesstraße 25, D-80992 München
Registergericht: Amtsgericht München, HRA 95603
Komplementärin: ORACLE Deutschland Verwaltung B.V. | Hertogswetering 163/167, 3543 AS Utrecht, Niederlande
Handelsregister der Handelskammer Midden-Nederland, Nr. 30143697
Geschäftsführer: Alexander van der Ven, Jan Schultheiss, Val Maher
<http://www.oracle.com/commitment> Oracle is committed to developing practices and products that help protect the environment
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/mlvm-dev/attachments/20160812/d4b3d1cb/attachment-0001.html>
More information about the mlvm-dev
mailing list