RFR: Classfile API stack maps processing

[Adam Sotona]

 What about another option to keep the status quo, drop PROCESS_STACK_MAP switch and do not stream StackMapAttribute at all?
As users can still access it from CodeModel::findAttribute(Attributes.STACK_MAP_TABLE) and manually pass it to CodeBuilder, which will then override even Generator.

This is more in line with how we handle BootstrapMethod attribute, and I think it is fine.  I think it is better, actually, because there is  no confusion about the interaction between "process" and "generate".  Here, "generate" indicates clear control over what to do with user-provided stack maps -- if we are in generate mode, ignore the user one.  No confusion.  So, +1 to this idea.

OK, done, with the “generator overrides all”.

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).

Per-method options to allow “hybrid” transformations can be solved in another round.

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

Thanks!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/classfile-api-dev/attachments/20220817/3950cbb1/attachment-0001.htm>