ClassFile API Labels limitations

[Brian Goetz]

Be careful.  When I revamped label handling (admittedly, early in the process), performance was very sensitive to the approach.  I tried half a dozen approaches.  Having multiple subtypes of labels definitely had a cost.

The main case we probably want to avoid regressing on is the mostly-no-op-adapataion case.

On Jan 15, 2024, at 9:30 AM, Adam Sotona <adam.sotona at oracle.com<mailto:adam.sotona at oracle.com>> wrote:

Hi,
ClassFile API Labels are always strictly linked with the source CodeModel or with the target CodeBuilder.
Only Labels coming from an existing CodeModel can be applied multiple times in various target CodeBuilders. Labels created by one CodeBuilder cannot be (re-)used in another CodeBuilder.
All these restrictions serve to the purpose of maximum performance.
However, this strict approach prevents to address not-yet existing code blocks or instructions outside of (or better say before the existence of) the CodeBuilder.

As an example, let’s say we plan to build a complex code structure from a custom abstract model.
Each of the addressable instruction or code block will be addressed by a Label at the build time, however that Label could not exist outside of the CodeBuilder.
Current workaround is to provide an extra mapping layer (a “CodeBuilderContext”) to translate from custom addressable elements to Labels (a unique new mapping for each CodeBuilder).

I would like to simplify this situation and here are some alternatives:


  1.  Introduce new Proto/Global/Unbound/UnresolvedLabel  (unsealed) interface.
And add CodeBuilder::resolve(ProtoLabel) method, which will identity-map it to a local Label during the build process.

or

  2.  Allow to statically create global Labels and make them reusable, it means to add static Label::newLabel() and fix current implementation.

I expect the static factory Label::newLabel() may attract users more than CodeBuilder::newLabel(), so the implementation should keep performance of the existing use cases.


Any comment and suggestions are welcome.

Thanks,
Adam

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/classfile-api-dev/attachments/20240115/0b1faea6/attachment-0001.htm>