Java – what is a stack mapping framework

I've been paying attention to Java virtual machine specifications (JVMs) recently, trying to better understand how my program works, but I found a part I don't know very well

Section 4.7 Section 4 describes the stackmaptable attribute. In this section, the document describes the stack mapping frame in detail The problem is that it is a little wordy. I learn best by example; Not through reading

I know that the first stack mapping frame is derived from the method descriptor, but I don't understand how (it is said that this is explained here) In addition, I don't fully understand the role of stack mapping frames I think they are similar to blocks in Java, but it looks like you can't stack frames inside each other

Anyway, I have two specific questions:

>What does the stack mapping framework do? > How do I create the first stack mapping framework?

There is also a general problem:

>Can anyone provide less and easier to understand explanations than those given in the JVMs?

Solution

Java requires that all loaded classes be verified to maintain sandbox security and ensure that code can be optimized safely Please note that this is done at the bytecode level, so the verification does not verify the invariants of the Java language. It only verifies whether the bytecode is meaningful according to the bytecode rules

In addition, bytecode verification ensures that the instruction format is correct, that all jumps are valid instructions in the method, and that all instructions operate on values of the correct type The last one is the source of stack mapping

The problem is that bytecode itself does not contain explicit type information The type is implicitly determined by data flow analysis For example, the iconst instruction creates an integer value If it is stored in slot 1, the slot now has int. if the control flow is merged from the code that stores floating points, the slot is now considered to have an invalid type, which means that you can no longer use this value to perform any operations until it is overwritten

Historically, bytecode validators have used these data flow rules to infer all types Unfortunately, it is not possible to infer all types in a single linear pass through bytecode, because a backward jump may invalidate the inferred types Classic validators solve this problem by iterating the code until everything stops changing, which may need to be passed multiple times

However, validation slows down class loading in Java Oracle decided to solve this problem by adding a new and faster verifier, which can verify bytecode in one pass To do this, they need all new classes starting from Java 7 (Java 6 is in transition) to carry metadata about their types so that bytecode can be verified at one time Since the bytecode format itself cannot be changed, this type of information is stored separately in a property named stackmaptable

Simply storing each value type at each single point in the code obviously takes up a lot of space and is very wasteful To make the metadata smaller and more efficient, they decided to let it list only the types of jump target locations If you think about it, this is the only time you need additional information for one-way verification Between jump targets, all control flows are linear, so you can infer types between locations using old inference rules

Each location where the type is explicitly listed is called a stack mapping frame The stackmaptable property contains a list of frames in order, but they are usually expressed as a difference from the previous frame to reduce the data size If there is no frame in the method, which occurs when the control flow will never be added (i.e. CFG is a tree), the stackmaptable attribute can be completely omitted

Therefore, this is the basic idea of how stackmaptable works and why it is added The last problem is how to create an implicit initial frame The answer, of course, is that at the beginning of the method, the operand stack is empty, and the local variable slot has the types given by the types of method parameters, which are determined from the method descriptor

If you are used to using Java, the way method parameter types work at the bytecode level will be slightly different First, the virtual method has an implicit first parameter Secondly, there are no Boolean, byte, character and short circuit at bytecode level Instead, they are implemented behind the scenes