javap with classfile API

[forax at univ-mlv.fr]

> From: "Rafael Winterhalter" <rafael.wth at gmail.com>
> To: "Remi Forax" <forax at univ-mlv.fr>
> Cc: "classfile-api-dev" <classfile-api-dev at openjdk.org>
> Sent: Tuesday, July 12, 2022 8:54:20 AM
> Subject: Re: javap with classfile API
In my previous mail, it should be, invokedynamic format is 5 bytes with the same encoding (* in practice *) as **invokeinterface** (not invokevirtual) 

> Ah, of course, I could have thought of that. Then I still wonder if it makes
> sense to show this zero in javap.

At least, this is not very consistent, invokeinterface does not show the last two bytes of it's encoding. So i guess invokedynamic should not show them too. 

Rémi 

> Remi Forax < [ mailto:forax at univ-mlv.fr | forax at univ-mlv.fr ] > schrieb am Di.,
> 12. Juli 2022, 00:21:

>>> From: "Rafael Winterhalter" < [ mailto:rafael.wth at gmail.com |
>>> rafael.wth at gmail.com ] >
>>> To: "classfile-api-dev" < [ mailto:classfile-api-dev at openjdk.org |
>>> classfile-api-dev at openjdk.org ] >
>>> Sent: Tuesday, July 12, 2022 12:09:06 AM
>>> Subject: javap with classfile API

>>> Hello,

>>> I completed a full round of comparing byte code output with ASM and OpenJDK's
>>> APIs and doing so, I was using the sandboxes version of javap. I found some
>>> errors in the tool doing so which I fixed for my own convenience on the way (if
>>> you wanted to adapt those fixes, [
>>> https://github.com/openjdk/jdk-sandbox/pull/21 |
>>> https://github.com/openjdk/jdk-sandbox/pull/21 ] , basically it makes the javap
>>> output identical to the ASM-based version).

>>> I was however wondering about printing dynamic constants:

>>> 1. For invokedynamic instructions,

>>> printConstantPoolRefAndValue(instr.invokedynamic(), 0)

>>> is used. I would not know why the 0 is printed here, but it was printed
>>> previously. Possibly, it was meant to yield an equivalent output for the
>>> "count" (JVMS 6.5) value of interface calls, but I do not see its value. Maybe
>>> this should be changed in javap.

>> invokedynamic format is 5 bytes with the same encoding as invokevirtual, the
>> opcode, two bytes for the constant and two bytes that are 0.
>> Those two bytes initially at 0 are used by the VM to reference the target of the
>> CallSite once the BSM is executed.

>> see [
>> https://docs.oracle.com/javase/specs/jvms/se18/html/jvms-6.html#jvms-6.5.invokedynamic
>> |
>> https://docs.oracle.com/javase/specs/jvms/se18/html/jvms-6.html#jvms-6.5.invokedynamic
>> ]

>>> 2. I changed the print of DynamicConstantPoolEntrys to

>>> print("#" + info.bootstrap().bsmIndex() + ":#" + info.nameAndType().index());

>>> , the same that is used in the string representation. Previously, the index was
>>> read via info.bootstrap().bootstrapMethod().index() - I do not quite understand
>>> why those two would be different, and bsmIndex seems to return 0 for lambda
>>> meta factory values, but it is indeed the old behavior. Maybe printing the
>>> reference to lambda meta factory would however be the better option. In this
>>> case, the string representation should however also be adjusted.

>>> 3. For handle types, the internal constant names were printed. Those are not
>>> part of the spec, so I changed it to print the documented REF_abc values. Those
>>> do however not indicate if a reference addresses an interface invocation; maybe
>>> this information should be included in javap.

>>> 4. I thought I found a row of issues with printing in-code type annotation type
>>> references, but it seems that javac has a row of issues with adding them to
>>> class files. So it's javac who gets those wrong, not javap. I validated that
>>> this has been an issue previously and is not related to the change in class
>>> file emitter. I reported these issues here ( [
>>> https://bugs.openjdk.org/browse/JDK-8290125 |
>>> https://bugs.openjdk.org/browse/JDK-8290125 ] ) but wanted to mention it if
>>> anybody ran into the same issue.

>>> Best regards, Rafael

>> Rémi
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/classfile-api-dev/attachments/20220712/0b83e5c0/attachment.htm>