Code model attribute hard-coded

[asotona]

This is yet another experimental serialization of code model into a custom method attribute.
It is based on #282 with all the ops tagged and hard-coded and a bit better utilization of constant pool.

Compiled size of the BytecodeTest class (with text-encoded code models) is 127531 bytes (30486 bytes as compressed in Jar), CP contains 1612 entries.
Cleaned size of the class (removed text-encoded code models and their static initialization) is 39044 bytes (16108 bytes in Jar), CP contains 1277 entries.
Size with models encoded in custom attributes is 57206 bytes (23114 bytes in Jar), CP contains 1452 entries.

Text-encoded code models add 88487 bytes (14378 bytes in Jar) and 335 CP entries to the class;
CodeModel attributes add only 18162 bytes (7006 bytes in Jar) and 175 CP entries.

---

Progress

• Change must not contain extraneous whitespace

Reviewing

Using git

Checkout this PR locally:
$ git fetch https://git.openjdk.org/babylon.git pull/290/head:pull/290
$ git checkout pull/290

Update a local copy of the PR:
$ git checkout pull/290
$ git pull https://git.openjdk.org/babylon.git pull/290/head

Using Skara CLI tools

Checkout this PR locally:
$ git pr checkout 290

View PR using the GUI difftool:
$ git pr show -t 290

Using diff file

Download this PR as a diff file:
https://git.openjdk.org/babylon/pull/290.diff

Using Webrev

Link to Webrev Comment

[bridgekeeper]

👋 Welcome back asotona! A progress list of the required criteria for merging this PR into code-reflection will be added to the body of your pull request. There are additional pull request commands available for use with this pull request.

[openjdk]

@asotona This change now passes all automated pre-integration checks.

ℹ️ This project also has non-automated pre-integration requirements. Please see the file CONTRIBUTING.md for details.

After integration, the commit message for the final commit will be:

Code model attribute hard-coded

You can use pull request commands such as /summary, /contributor and /issue to adjust it as needed.

At the time when this comment was updated there had been 10 new commits pushed to the code-reflection branch:

• 5deaf0f: Hat add jextract to maven
• d63c0f7: Added hat nbody opengl example
• ee2789e: Added hatless nbody example
• e40d8a3: More jextract prep
• ae52afe: More bld simplifications. Prep for adding jextract
• 54f1b92: mkpoms cleanup + .gitignore target dirs
• 2f2d7d6: Added mkpoms script - updated bldr/XMLNode
• 52eba9d: Some build fixups after merging hip backend
• 95445c8: HIP HAT backend
• 0101fa4: using auto generated poms also a fix for CustomOpTest

Please see this link for an up-to-date comparison between the source branch of this pull request and the code-reflection branch.
As there are no conflicts, your changes will automatically be rebased on top of these commits when integrating. If you prefer to avoid this automatic rebasing, please check the documentation for the /integrate command for further details.

➡️ To integrate this PR with the above commit message to the code-reflection branch, type /integrate in a new comment.

[mlbridge]

Webrevs

• 01: Full - Incremental (15f241e3)
• 00: Full (7a94d8db)

[mcimadamore]

In terms of maintenance, I wonder if there could be a way to connect the tag more directly to the op classes. E.g. so that if an op is added/removed, we may rely on static checks to detect that our reading/writing logic needs updating.

But maybe that works already: after all, the writing logic does a switch on the op instance - if that switch is made exhaustive, we could prevent mistakes when new ops are added. (when ops are removed, the mistake will be detected more easily, as the serialization code will refer to no longer existing classes).