On Thu, Feb 6, 2014 at 5:46 PM, Charles Oliver Nutter
<head...@headius.com>wrote:

> A lot more code is working now that I've just opted to back off
> specializing anything beyond what the IR does itself.


Makes sense. Let us fix the IR and add any missing info to make sure what
JIT gets is mostly ready to go.


> I also have closures basically working now, though non-local flow control
> still requires too much data from IR structures to implement right now
> (non-local break and return, for example).
>

Yes, we still have to add info to StaticScope to remove dependency on
IRScope. IRStaticScope was a "temporary" fix to get IR mode functional
without disrupting / touching existing runtime.


>
> I also ran into an issue with how heap variable assignment is being
> optimized:
>
> for the closure passed to foo: a = 'here'; foo { a = 'bar'; puts a }
>
> Linearized instructions for JIT:
> 0 thread_poll
> 1 line_num(0)
> 2 %t_a_1 = "bar"
> 3 %cl_1_0 = call_1o(FUNCTIONAL, 'puts', %self, [%t_a_1]){1O}
> 4 store_lvar(%t_a_1, -e_CLOSURE_1, a(1:0))
> 5 return(%cl_1_0)
> 6 %cl_1_2 = recv_jruby_exc
> 7 store_lvar(%t_a_1, -e_CLOSURE_1, a(1:0))
> 8 runtime_helper(catchUncaughtBreakInLambdas, [%cl_1_2])
>
> The exception table here handles exceptions from 0 to 5 by branching to 6.
> However, 7 attempts to load a value first assigned within that catch range.
> When I try to compile this to JVM bytecode, it fails because there's no
> guarantee that %t_a_1 has been assigned before 7 runs.
>

This looks like a bug in the AddLocalVarLoadStoreInstrs pass ...  It should
have dumped dirty vars at all sites that could raise excs.  -- in this case
before the puts.
Will take a look in the coming days.

We should also think about adding additional tests beyond rubyspecs to
stress test some of this ... given that the rubyspec run is back to old
state (10 fails, 3 errors) with this pass enabled.

Subbu.


> In any case, things are moving along well. There's a few things to fix and
> lots of things to optimize, but progress is being made.
>
> - Charlie
>

Reply via email to