RFR: Classfile API stack maps processing

[Adam Sotona]

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
  *   StackMapTableAttribute become 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/3715da36/attachment-0001.htm>