public final Class StackMapGenerator

Stack map frames are computed from serialized bytecode similar way they are verified during class loading process.

The frames computation consists of following steps:

1. Detection of mandatory stack map frames:
   • Mandatory stack map frame include all jump and switch instructions targets, offsets immediately following "no control flow" and all exception table handlers.
   • Detection is performed in a single fast pass through the bytecode, with no auxiliary structures construction nor further instructions processing.
2. Generator loop processing bytecode instructions:
   • Generator loop simulates sequence instructions processing effect on the actual stack and locals.
   • All mandatory frames detected in the step #1 are retro-filled (or reverse-merged in subsequent processing) with the actual stack and locals for all matching jump, switch and exception handler targets.
   • All frames modified by reverse merges are marked as dirty for further processing.
   • Code blocks with not yet known entry frame content are skipped and related frames are also marked as dirty.
   • Generator loop process is repeated until all mandatory frames are cleared or until an error state is reached.
   • Generator loop always passes all instructions at least once to calculate max stack and max locals code attributes.
   • More than one pass is usually not necessary, except for more complex bytecode sequences.
     (Note: experimental measurements showed that more than 99% of the cases required only single pass to clear all frames, less than 1% of the cases required second pass and remaining 0,01% of the cases required third pass to clear all frames.).
3. Dead code patching to pass class loading verification:
   • Dead code blocks are indicated by frames remaining without content after leaving the Generator loop.
   • Each dead code block is filled with NOP instructions, terminated with ATHROW instruction, and removed from exception handlers table.
   • Dead code block entry frame is set to java.lang.Throwable single stack item and no locals.

Reverse-merge of the stack map frames may in some situations require to determine class hierarchy relations.

Reverse-merge of individual types is performed when a target frame has already been retro-filled and it is necessary to adjust its existing stack entries and locals to also match actual stack map frame conditions. Following tables describe how new target stack entry or local type is calculated, based on the actual frame stack entry or local ("from") and actual value of the target stack entry or local ("to").

Array types are reverse-merged as reference to array type constructed from reverse-merged components. Reference to j.l.Object is an alternate result when construction of the array type is not possible (when reverse-merge of components returned TOP or other non-reference and non-primitive type).

Custom class hierarchy resolver has been implemented as a part of the library to avoid heavy class loading and to allow stack maps generation even for code with incomplete dependency classpath. However stack maps generated with warnings of unresolved dependencies may later fail to verify during class loading process.

Focus of the whole algorithm is on high performance and low memory footprint:

• It does not produce, collect nor visit any complex intermediate structures (beside traversing the bytecode in binary form).
• It works with only minimal mandatory stack map frames.
• It does not spend time on any non-essential verifications.