Mapping byte code offsets in custom code attributes

[Rafael Winterhalter]

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>:

> 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> on behalf
> of Chen Liang <chen.l.liang at oracle.com>
> *Date: *Monday, 11 November 2024 at 0:28
> *To: *Rafael Winterhalter <rafael.wth at gmail.com>, classfile-api-dev <
> 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> on behalf
> of Rafael Winterhalter <rafael.wth at gmail.com>
> *Sent:* Saturday, November 9, 2024 2:32 AM
> *To:* classfile-api-dev <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/80d1a963/attachment-0001.htm>