javap with classfile API

[Rafael Winterhalter]

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

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

>
>
> ------------------------------
>
> *From: *"Rafael Winterhalter" <rafael.wth at gmail.com>
> *To: *"classfile-api-dev" <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, 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
>
>
> 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) 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/bf149247/attachment-0001.htm>