Classfile API is missing CodeBuilder hook for various instructions-consuming computation tools

[Adam Sotona]

From: Brian Goetz <brian.goetz at oracle.com>
That's what I thought.  So, since they are only applied when you really need them, can't these be treated as "generate the classfile, and then traverse it as a classfile with the API we already have?"  This seems like it would work in all the cases when we *can* generate a classfile, which leaves the cases where we would fail to generate a classfile and therefore have nothing to analyze, which is probably a non-zero but not-large fraction of the cases, right?
Right, all these cases are to support generation in progress. Can we now even start transformation of a bytecode fragment that has not been finished yet (with our current API) ?
I think using transformations for these cases is an overkill. We just need to dynamically collect various information from the actual CodeBuilder. These should be much tighter co-processors connected to CodeBuilder.
I think you misunderstood my question.  I didn't mean "is this useful in transformation".  I meant that, we *already* have composable transforms, where the output of one activity is piped into another; there's a lot of similarity here (and they'll use the same underlying plumbing.)  I was suggesting that you could think of teeing as being a (likely no-op) transformation on the building that is already in progress.

Using composable transformations for example to calculate actual stack content to emit multiple stack-to-locals and locals-to-stack sequences of instructions – that is beyond my  imagination yet.
I’ve previously re-used javac stack tracker to implement this particular feature, where javac had full control of each individual instruction, so it was able to instruct stack-to-locals and back. However such approach prevents use of any advanced CodeBuilder features. When you for example optimize the code generator to use blocks, you lose track of the exact instructions passing down to the CodeBuilder::with.
This API proposes an option to add listener of what falls down to the CodeBuilder when drop something into some of its convenience methods.
I’m open to any other proposal how to hook these code helpers. We may for example implement them internally and enable them with specific switches. However even for the internal helpers we still need a hook to listen on CodeBuilder. Actually there is a hard-coded partial support for local variables allocation, which should also fall into this group of code-builder helpers (actually tracking instructions related to local variables).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/classfile-api-dev/attachments/20220819/ba34df4b/attachment.htm>