<html><body><div id="zimbraEditorContainer" style="font-family: arial, helvetica, sans-serif; font-size: 12pt; color: #000000" class="40"><div><br></div><div><br></div><hr id="zwchr" data-marker="__DIVIDER__"><div data-marker="__HEADERS__"><blockquote style="border-left:2px solid #1010FF;margin-left:5px;padding-left:5px;color:#000;font-weight:normal;font-style:normal;text-decoration:none;font-family:Helvetica,Arial,sans-serif;font-size:12pt;"><b>From: </b>"Rafael Winterhalter" <rafael.wth@gmail.com><br><b>To: </b>"Remi Forax" <forax@univ-mlv.fr><br><b>Cc: </b>"classfile-api-dev" <classfile-api-dev@openjdk.org><br><b>Sent: </b>Tuesday, July 12, 2022 8:54:20 AM<br><b>Subject: </b>Re: javap with classfile API</blockquote><div><br></div><div>In my previous mail, it should be, invokedynamic format is 5 bytes with the same encoding (* in practice *) as **invokeinterface** (not invokevirtual) </div><div><br data-mce-bogus="1"></div></div><div data-marker="__QUOTED_TEXT__"><blockquote style="border-left:2px solid #1010FF;margin-left:5px;padding-left:5px;color:#000;font-weight:normal;font-style:normal;text-decoration:none;font-family:Helvetica,Arial,sans-serif;font-size:12pt;"><div dir="auto">Ah, of course, I could have thought of that. Then I still wonder if it makes sense to show this zero in javap.</div></blockquote><div><br></div><div>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.<br data-mce-bogus="1"></div><div><br data-mce-bogus="1"></div><div>Rémi<br data-mce-bogus="1"></div><div><br data-mce-bogus="1"></div><blockquote style="border-left:2px solid #1010FF;margin-left:5px;padding-left:5px;color:#000;font-weight:normal;font-style:normal;text-decoration:none;font-family:Helvetica,Arial,sans-serif;font-size:12pt;"><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Remi Forax <<a href="mailto:forax@univ-mlv.fr" target="_blank">forax@univ-mlv.fr</a>> schrieb am Di., 12. Juli 2022, 00:21:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div id="m_-4530647462541055376zimbraEditorContainer" style="font-family:arial,helvetica,sans-serif;font-size:12pt;color:#000000"><br><br><hr id="m_-4530647462541055376zwchr"><div><blockquote style="border-left:2px solid #1010ff;margin-left:5px;padding-left:5px;color:#000;font-weight:normal;font-style:normal;text-decoration:none;font-family:Helvetica,Arial,sans-serif;font-size:12pt"><b>From: </b>"Rafael Winterhalter" <<a href="mailto:rafael.wth@gmail.com" target="_blank" rel="noreferrer">rafael.wth@gmail.com</a>><br><b>To: </b>"classfile-api-dev" <<a href="mailto:classfile-api-dev@openjdk.org" target="_blank" rel="noreferrer">classfile-api-dev@openjdk.org</a>><br><b>Sent: </b>Tuesday, July 12, 2022 12:09:06 AM<br><b>Subject: </b>javap with classfile API<br></blockquote></div><div><blockquote style="border-left:2px solid #1010ff;margin-left:5px;padding-left:5px;color:#000;font-weight:normal;font-style:normal;text-decoration:none;font-family:Helvetica,Arial,sans-serif;font-size:12pt"><div dir="ltr"><div>Hello,</div><br><div>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, <a href="https://github.com/openjdk/jdk-sandbox/pull/21" target="_blank" rel="noreferrer">https://github.com/openjdk/jdk-sandbox/pull/21</a>, basically it makes the javap output identical to the ASM-based version).</div><br><div>I was however wondering about printing dynamic constants:</div><br><div>1. For invokedynamic instructions, </div><br><div> printConstantPoolRefAndValue(instr.invokedynamic(), 0)</div><br><div> 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.</div></div></blockquote><br><div>invokedynamic format is 5 bytes with the same encoding as invokevirtual, the opcode, two bytes for the constant and two bytes that are 0.<br></div><div>Those two bytes initially at 0 are used by the VM to reference the target of the CallSite once the BSM is executed.<br></div><br><div>see <a href="https://docs.oracle.com/javase/specs/jvms/se18/html/jvms-6.html#jvms-6.5.invokedynamic" target="_blank" rel="noreferrer">https://docs.oracle.com/javase/specs/jvms/se18/html/jvms-6.html#jvms-6.5.invokedynamic</a><br></div><br><blockquote style="border-left:2px solid #1010ff;margin-left:5px;padding-left:5px;color:#000;font-weight:normal;font-style:normal;text-decoration:none;font-family:Helvetica,Arial,sans-serif;font-size:12pt"><div dir="ltr"><br><div>2. I changed the print of DynamicConstantPoolEntrys to <br></div><br><div> print("#" + info.bootstrap().bsmIndex() + ":#" + info.nameAndType().index());</div><br><div>, 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.</div><br><div>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.</div><br><div>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 (<a href="https://bugs.openjdk.org/browse/JDK-8290125" target="_blank" rel="noreferrer">https://bugs.openjdk.org/browse/JDK-8290125</a>) but wanted to mention it if anybody ran into the same issue.</div><br><div>Best regards, Rafael</div></div></blockquote><br><div>Rémi<br></div></div></div></div></blockquote></div><br></blockquote></div></div></body></html>