Skip to content

StackMap table

episode edited this page Nov 28, 2024 · 1 revision

The stackmap table isn't an instruction, but it's important to know about if you're messing with bytecode. It's used during bytecode verification, which happens when a class is loaded.

It was introduced in Java 6 and became mandatory in Java 7. Its job is to tell the JVM about the state of the operand stack and local variables at certain points in a method. This lets the JVM verify the bytecode faster, but it also makes your class files a bit fatter.

Here's what you need to know:

It's in the Code attribute of methods.
It's got entries (frames) for specific points in the bytecode:
    Start of each exception handler
    After any instruction that isn't right after its predecessor
    This means jump targets, but also after unconditional jumps or returns
Each frame describes what types are in the locals and on the stack at that point.
There are different types of frames (full, append, chop, etc.) to keep things efficient.
The verifier uses this to check the bytecode without having to simulate running it.

If you're obfuscating code, you need to be careful with the stackmap table. If you fuck it up, the JVM won't load your class. But if you can generate valid stackmap tables for weird bytecode, you can make some really nasty obfuscation.

Clone this wiki locally