Improve the performance of accessing ThreadedBlockData.

[copi143]

For functions that need to access fields inside ThreadedBlockData multiple times, cache the ThreadedBlockData object at the start of the function instead of retrieving it from the ThreadLocal each time.

[Alexdoru]

doesn't work

[copi143]

Yes. analyzer.analyze can sometimes throw odd exceptions. On my machine, a subset of classes consistently fail to be handled correctly, so I added an analyzeSuccess variable to fall back to the original implementation on failure.

[copi143]

Oh no. It seems there are other strange issues as well. I'll try to fix it, overall it shouldn't be worse than before for now.

[Alexdoru]

that's gonna need a safe class writer to not blow up

[copi143]

Now analyzer.analyze will no longer run for a large number of unrelated methods.

[Alexdoru]

your implementation always injects at the head of the method which will crash if the method is a constructor

[Alexdoru]

you need to increment the local variable name in case it injects multiple local variables

[Alexdoru]

is it possible to move the local variable allocation closer to where it's used to avoid cases where it will get the data but not use it

[copi143]

you need to increment the local variable name in case it injects multiple local variables

Actually, incrementing names aren't necessary because I'm using unique IDs.
The name is just for easier decompilation and debugging.

[copi143]

is it possible to move the local variable allocation closer to where it's used to avoid cases where it will get the data but not use it

This would be quite complicated, and the following situations might occur:

if (xxx) {
    cache = ...
    cache.x
    cache.y
}
cache.z

[danyadev]

you don't need most of the reorganization changes in your pr now, it already got refactored in master, so you don't need to reorder fields and to keep methods like isBlockSubclass, trackBlockSubclasses and trackBlockShadowingFields