Some ideas from discussing with Tom:

• Initial move could be to add a new DynamicScope that supports arbitrarily-many variables (like ManyVars) and which does null checking. Remove null checking from the other scopes, since they'll only be made by Full and JIT.
• Any methods that currently null check would need to keep null-checking, for non-Ruby code that doesn't have guarantees about initialization. Ruby code would call through new non-checked paths. This may be a way to avoid adding a new DynamicScope type at the cost of duplicating all current null-checking methods (i.e. Simple just uses existing null-checked methods, Full and JIT move to using unchecked methods).
• It may be time we bought or built a library that can generate specialized collections from a template. For example, we don't want to have to maintain N DynamicScope classes in source for N widths of frame...better would be to have one template and generate those N classes at runtime as needed. This also allows us to potentially make JIT go directly at fields on those generated objects, something that was infeasible with full null checking.

Any methods that currently null check would need to keep null-checking, for non-Ruby code that doesn't have guarantees about initialization. Ruby code would call through new non-checked paths. This may be a way to avoid adding a new DynamicScope type at the cost of duplicating all current null-checking methods (i.e. Simple just uses existing null-checked methods, Full and JIT move to using unchecked methods).

My thought as well.

I've merged my PR that adds unchecked get* paths to all DynamicScope types. It also removes a scope type we no longer used, and fixes a null leak from Thread#name uncovered by the DynamicScope changes.

Note also that this PR only uses the unchecked paths from JIT, since Full IR still needs a way to indicate that a LocalVariable access should be unchecked. Currently LocalVariable.retrieve uses DynamicScope.getValue(offset, depth) and does its own null checking, and I believe some of the interpreter logic short-circuits the retrieve call and goes after DynamicScope directly.

@enebo How/where should we change full IR or full interpreter to use the unchecked paths?

@headius I can change it. It is retrieveOp in InterpreterEngine but I need to make sure Startup is not using that version.

You guys both asked me about perf. Here's a trivial bench:

[] ~/projects/jruby $ jruby -Xcompile.invokedynamic -e 'a = 0; b = 1; c = 2; d = 3; loop { t = Time.now; a = 0; while a < 100_000_000; a+=1; b, c, d = c, d, b; end; puts Time.now - t }'
1.851
1.659
1.544
1.682
1.466
1.449
1.438
^C
[] ~/projects/jruby $ rvm jruby-9.1.5.0 do jruby -Xcompile.invokedynamic -e 'a = 0; b = 1; c = 2; d = 3; loop { t = Time.now; a = 0; while a < 100_000_000; a+=1; b, c, d = c, d, b; end; puts Time.now - t }'
1.779
1.708
1.809
1.907
1.795
1.713
1.752
1.774
^C

This is a pretty good result, considering the loop itself takes a good portion of this:

[] ~/projects/jruby $ jruby -Xcompile.invokedynamic -e 'a = 0; loop { t = Time.now; a = 0; while a < 100_000_000; a+=1; end; puts Time.now - t }'
1.448
1.333
1.15
1.26
1.085
1.073
1.095
1.183
1.082
^C
[] ~/projects/jruby $ rvm jruby-9.1.5.0 do jruby -Xcompile.invokedynamic -e 'a = 0; loop { t = Time.now; a = 0; while a < 100_000_000; a+=1; end; puts Time.now - t }'
1.332
1.248
1.321
1.427
1.239
1.202
1.207
1.216
^C

So the three-variable swapping is maybe 0.37s on master+#4168 and 0.55s on 9.1.5.0, so that's around a 30% improvement. Not bad!

@headius nice!

For those who follow our issues and want a little more background on impact...We try to eliminate heap variable scopes as much as we can. If a method has a closure in it then we end up generating a variable scope since we do not generally know whether that closure could end up becoming a binding. This change ends up improving variable access times whenever we have a heap scope. So if a method contains a closure it will likely see this improvement (it obviously may get watered down based on what else you do in that method). We do also create scopes for other reasons (like some native methods) but mainly you will notice the improvement in methods containing blocks.

For fun I ran the microbench against 1.7 with and without indy on and we are twice as fast in both modes as 1.7 now. I am not sure if that is because of our IR opts or because we now have some mandatory indy stuff wired in on 9k. Still, it is fun to see us improving relative to 1.7.x.

Yes, good results. Better than I anticipated even.

This is not addressed in full interpreter but I am closing this as resolved since we have it where it matters (JIT) and I want it in 9.1.6.0 issue list.