RFR: Classfile API stack maps processing

[Brian Goetz]

> The access to manual processing of stack maps is a bit hidden, however 
> available.
>
> We may later change decision to stream the SMTA (based on any existing 
> switch or a new one) and it won’t affect processing. I figured out how 
> to inflate remaining labels without loose of performance (without 
> inflation of the whole SMTA).
>

If we want to do that later, we can make SMTA a CompositeElement, where 
the frames are the elements, and a corresponding builder. Building would 
then produce an unbound SMTA which could be fed to 
CodeBuilder::withAttribute.

> One thing remains (also for another round) – we still use defaults for 
> maxLocals and maxStack when the generator is off.

In the process of doing the local variable allocation stuff, I added 
some support for doing better, but it's not 100% yet.  It carries over 
maxLocal/maxStack during adaptation, and adjusts maxLocal based on 
allocated locals.  But it would need some more work to be reliable, 
since you can do your own manual local management.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/classfile-api-dev/attachments/20220817/809b9f5a/attachment.htm>