RFR: Classfile API stack maps processing

[Brian Goetz]

See the RFR, I think I found a place where we might end up putting TWO 
stack map attributes into the builder.

With this patch, I believe the treatment of stack maps is intended to be:

    if (generation not disabled) {
        try to reuse original stackmap, if transforming and code 
array/exception table is unchanged
        otherwise generate stack map
    }
    else {
        if a stack map has been sent to the builder, put that in the 
class file
    }

I am not sure this is the effect, though; since the user can send stack 
maps down the pipe and they are stored as attributes regardless of 
options, I think these may be written to the classfile even if we are in 
generation mode.



On 8/17/2022 11:45 AM, Adam Sotona wrote:
>
> Hi,
>
> I would like to ask for review of proposed change in the Classfile API 
> stack maps processing.
>
> Primary motivation is to better align stack maps processing with the 
> Classfile API and to allow manual constructions and transformations of 
> stack maps.
>
> Pull request for review is here: 
> https://github.com/openjdk/jdk-sandbox/pull/32
>
> And it includes following changes:
>
>   * New boolean Classfile.Option::processStackMaps with default to
>     false has been added
>   * StackMapTableAttributebecome a CodeElement processed when the
>     above option is explicitly enabled by user
>   * StackMapTableAttribute, StackMapFrameInfo, VerificationTypeInfo,
>     SimpleVerificationTypeInfo, ObjectVerificationTypeInfo and
>     UninitializedVerificationTypeInfo have been simplified, refactored
>     to use Labels instead of offsets and equipped with relevant static
>     factory methods
>   * Redundant content of the StackMapFrameInfo and its sub-classes
>     reflecting compressed frame forms have been removed
>   * UnboundStackMapTableAttribute with proper serialization has been
>     implemented
>   * CorpusTest with RebuildingTransformations has been extended to
>     process stack maps using the new API
>
> New stack maps processing option affects inflation of stack maps and 
> appearance of StackMapTableAttribute in the CodeElement stream.
>
> Enabled stack maps processing inflates and decompresses 
> StackMapTableAttribute with translated offsets to Labels and pass it 
> to CodeTransformation(s).
>
> User can individually filter StackMapTableAttribute out or transform 
> it manually when explicitly enabled stack maps processing.
>
> User-provided or transformed StackMapTableAttribute passed to 
> CodeBuilder overrides stack maps generation process for the actual method.
>
> Compressed source form of the parsed stack map frame can be identified 
> from StackMapFrameInfo::tag
>
> All new created StackMapFrameInfos always represent full frames with 
> complete list of locals and stack.
>
> Compression of StackMapTableAttribute frames is contextual operation 
> and it is applied at the writing phase.
>
> Any NO-OP transformation of inflated and decompressed 
> StackMapTableAttribute may result in a different compressed form.
>
> Performance boost tricks by-passing stack maps generation for 
> unchanged methods are unaffected by this enhancement.
>
> Thanks for your comments,
>
> Adam
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/classfile-api-dev/attachments/20220817/c810a0cb/attachment.htm>