[External] : Re: Mapping byte code offsets in custom code attributes

[Adam Sotona]

Hi Rafael,

Code-level attributes are decomposed to code elements, streamed/transformed as pseudo-instructions together with the bytecode instructions and composed back to the relevant attributes by Class-File API. To insert a new line number, you can call CodeBuilder::lineNumber at required position of code building or transformation. This is the way covering 99% of use cases.

Javap is an example of the “raw” attributes consumers minority.

After JDK-8341274 you will be able to receive a Label for a valid bytecode offset in your CustomAttribute mapper. Each Label position is identified by relevant LabelTarget in the CodeModel stream. All targeted labels are resolved to target bytecode offsets automatically for known code elements and attributes. All targeted labels will be also resolvable to the target bytecode offsets in custom attribute mappers after JDK-8341274.

Unfortunately, class file transformation is so complex process with many different use cases, aspects, and contradicting priorities that we cannot always provide equal level of support for everything with shining perfect API symmetry. I think custom code attributes operating with bytecode offsets should be provided with at least basic level of Class-File API support.  However I would not expect the same seamless integration as for the JVMS-defined attributes.

Adam



From: Rafael Winterhalter <rafael.wth at gmail.com>
Date: Monday, 11 November 2024 at 9:42
To: Adam Sotona <adam.sotona at oracle.com>
Cc: Chen Liang <chen.l.liang at oracle.com>, classfile-api-dev <classfile-api-dev at openjdk.org>
Subject: [External] : Re: Mapping byte code offsets in custom code attributes
Hei Adam,

I agree that most use cases should be covered by today's API. I already use the former in my bridge implementation to use ASM with the Class File API. When it comes to LineNumberTableAttribute, I do not understand how it can be useful to resolve the remaining 1%, though. LineNumberInfo is built around a "startPc". Without an opportunity to resolve a BCI for a generated method, I do not understand how I can create a custom line number table attribute using the Class File API. The CodeBuilder interface does not expose the created CodeAttribute, which would be needed to resolve a label position to the needed BCI that the LineNumberInfo class requires. At a minimum, I would need CodeBuilder to resolve the current byte code index, but in the end this would only be used to build a custom label mechanism. I argue that this should already be handled by the API. The same goes for reading. I can of course count the size of each encountered instruction and keep a custom mapping of attributed BCIs to invoke a custom callback whenever a relevant offset is discovered, but this is also what the Label API is used for, and I think the API should handle this mapping.

I find the same limitation with LocalVariableTypeInfo, LocalVariableInfo and CharacterRangeInfo. I also believe this was considered for type annotations where TypeAnnotation.TargetInfo.OffsetTarget resolves a label, and not a BCI. I expected consistent handling for all attributes other than type annotations, including custom attributes.

Best regards, Rafael

Am Mo., 11. Nov. 2024 um 09:17 Uhr schrieb Adam Sotona <adam.sotona at oracle.com<mailto:adam.sotona at oracle.com>>:
Hi Rafael,

LineNumber, LocalVariable and LocalVariableType (as CodeElements) are integral parts of the Class-File API and they should serve well to 99% of user use cases.

In addition, LineNumberTableAttribute, LocalVariableTableAttribute, LocalVariableTypeTableAttribute and StackMapTableAttribute are available in “raw” forms to support strongly requested specific corner cases.

This is clear request to support custom code-level attributes with references to bytecode offsets.
I agree with Chen that  JDK-8341274 should be sufficient to resolve it.

Thank you,
Adam




From: classfile-api-dev <classfile-api-dev-retn at openjdk.org<mailto:classfile-api-dev-retn at openjdk.org>> on behalf of Chen Liang <chen.l.liang at oracle.com<mailto:chen.l.liang at oracle.com>>
Date: Monday, 11 November 2024 at 0:28
To: Rafael Winterhalter <rafael.wth at gmail.com<mailto:rafael.wth at gmail.com>>, classfile-api-dev <classfile-api-dev at openjdk.org<mailto:classfile-api-dev at openjdk.org>>
Subject: Re: Mapping byte code offsets in custom code attributes
Hi Rafael,
You are correct.  I had previously created an issue https://bugs.openjdk.org/browse/JDK-8341274 to track this demand.  Since this scenario has no way to bypass, maybe we can raise this issue to P3 and work on this feature for JDK 24.  Also I wonder how frequently are custom attributes storing BCIs?

For LineNumberInfo: I believe the Label-based version, LineNumber, is already streamed in class file reading, and can be sent to the builder also via CodeBuilder::lineNumber(int).  Your particular use case can probably be covered by the RFE too, once we can convert labels to BCIs in non-Code attributes.

Regards,
Chen Liang
________________________________
From: classfile-api-dev <classfile-api-dev-retn at openjdk.org<mailto:classfile-api-dev-retn at openjdk.org>> on behalf of Rafael Winterhalter <rafael.wth at gmail.com<mailto:rafael.wth at gmail.com>>
Sent: Saturday, November 9, 2024 2:32 AM
To: classfile-api-dev <classfile-api-dev at openjdk.org<mailto:classfile-api-dev at openjdk.org>>
Subject: Mapping byte code offsets in custom code attributes

Hello,

I mentioned before that I think there is still a missing bit when it comes to custom code attributes, and mapping them using an AttributeMapper. Many code attributes point to a location, or area, within a method. This typically implies specifying one or two byte code offsets within an attribute.

To implement this, I would need a possibility to translate offsets to labels within an attribute mapper, and vice versa. For example, if I created byte code from a different source, where a method consists of multiple files, I would want to mark what part of the method comes from what file.

I do not currently know of a way to do this in the Class File API. To resolve this, I would have hoped that the attribute reader method would be able to issue labels that are later issued when the code instructions are supplied. Similarly, I would have hoped that the attribute writer method would be capable of translating labels to byte code offsets.

In the same way, I would have hoped that all attributes such as LineNumberInfo of the LineNumberTableAttribute would expose bytecode offsets as labels and not as integers, as the latter does not really give any useful information by itself. This way, I could also write a custom LineNumberTableAttribute after a method is already created by issuing relevant labels, but by only writing the attribute when the entire method was visited. Sometimes this is necessary when generating code, when the information about the actual line numbers is only retrieved at a later stage that requires knowledge of the entire method.

As I understand it, the ClassFile API is supposed to be released in Java 24. Are there still plans to integrate such a change? After that it would require incompatible changes, therefore I had hoped this would make it into the final version.

Thanks! Rafael
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/classfile-api-dev/attachments/20241111/d4e5c192/attachment-0001.htm>