Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Remove premade field-based DynamicScope and generate instead. #4174
Instead of having hand-written DynamicScope subtypes that use
Currently it only overrides the base getValue and setValue methods
I did a prototype of directly accessing fields from the specialized scopes. It worked reasonably well, but there's a few snags. It does not boot properly (because I removed ManyVarsDynamicScope and other classes that are actually still needed), but it does generate the expected code.
The comparative bytecode is here: https://gist.github.com/headius/2c0b2459d8e5fb3c69bbaec254295ea8
This should have better performance than any previous mechanism, unless the checkcast is killing us. Just an experiment for now.
The concerns I had/have are:
The biggest improvement in this PR from beginning to end is that there are now ten offset-specialized get/set methods that are generated for all specialized DynScopes, and the JIT will automatically use them. Adding more requires only implementing them in DynamicScope and ManyVarsDynamicScope and adding their names to the lists in DynamicScopeGenerator. These methods allow heap variable accesses to inline down to a single field read or write with no extra overhead.
Inlining-wise at the JVM level, a given jitted code body will generally have only one StaticScope and will only ever see one DynamicScope type, so every method body should be able to inline logic for its own scope.
I have not revisited the direct field access because I was able to expand the use of offset-specialized methods. However, it might be interesting to see indy-based scope var access, which could specialize beyond the base set of offsets. I have no plans to do this right now.
Two trivial comments. My only reservation I think we will need to wait and see...we keep increasing our dependence of invokedynamic.