RFR: Classfile API stack maps processing

[Brian Goetz]

>  1. Processing stack maps is extremely advanced feature and 99.9% of
>     users don’t want to touch it, so why PROCESS_STACK_MAPis off by
>     default and GENERATE_STACK_MAPS is on by default
>

Agree with this.

>  1. When the 0.1% user needs to process the stack maps, he needs full
>     control over it. So when user enables PROCESS_STACK_MAP, full
>     control of what drops to code builder is up-to user.
>

OK, I don't mind two options, but I'd like to be clear on what they 
mean.  I don't think that merely turning on PROCESS_STACK_MAP will clue 
the user in to the fact that they have disengaged all the safety 
guards.  Some users may just want to _read_ the stack map. So I'm OK 
with having both PROCESS and GENERATE options, but we should be clear 
what they mean, and be conservative in their meanings.  Here's what 
makes sense to me:

GENERATE: the stack map is *always* generated by the library.  Any stack 
maps sent downstream are still ignored.
PROCESS: send the stack map to the user.
PROCESS & !GENERATE: send the stack map to the user, write any stack map 
the user supplied to the classfile.

So users who want full control select PROCESS and !GENERATE; users who 
want to see the stackmap select PROCESS only; users who don't care about 
stack maps (which is most of them) select neither.

I think what this exposes is we need a way to override some options on a 
per-method basis, which is a separate problem.

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