Won't this result in unnecessary repeated recompiles?

For example in a code like this:

arr = (0..10_000).to_a # a dataset

def compute(x) # work fun, on some inputs it might throw an error
  1000 / x
end

100.times do
  arr.shuffle.each do |v|
    begin
      compute(x)
    rescue
      # log an error, we ignore invalid inputs
    end
  end
end

Isn't it the case, that previously foo (or the containing each block) would compile, run at full speed, on exception transfer to interpreter, throw an error, and then go back into full speed JIT-ed code? Whereas now on transfer it additionally discards the JIT-ed code, recompiles foo again (into an identical machine code) and then go back to full speed?

Before ~999,900 compiled calls, 100 transfers; after: ~999,900 compiled calls, 100 transfers, 100 identical recompiles of compute? What am I missing?

@thedarkone It could, but in practice transferToInterpreter is almost never the right tool.
In a dynamic compiler, one needs to make sure the code does not continuously deoptimize, so once we do we want to take action so it does not happen a second time for the same reason (or a very small bounded number of times).

An error like a division by 0 should first deopt, then be checked actively (raise if b == 0) so it does not deopt anymore. So we really want only 1 transfer there.
BTW, rescue nor throwing a Ruby exception needs a transfer.

But, currently the division node is indeed bugged because it never checks actively for b == 0 and relies wrongly on the ArithmeticException which is always a deopt. Fix coming...

@thedarkone The division by zero thing is fixed as of fd17285.
Now it compiles into a nice mostly-empty loop with no deopts.

Alright, I get it, you like to invalidate things 😝.

Trans&invalidates look fine to me in cases of unreachable defaults and right before insert(), but I think you should audit all other cases (similarly to that div by Fixnum 0).

I think there are other zeroDivisionError, also check out:

• 1fdc645#diff-bfae10c1533cd81908501609a871b496R36
• 1fdc645#diff-bfae10c1533cd81908501609a871b496R36

I went scrolling upwards and gave up after about 20% of the commit, I'll leave the rest of it up to you guys!

@thedarkone Good catch, indeed that one should be profiled instead.
The reason I did it for all usages is even if transferToInterpreter would be more appropriate, is it does not produce good results either as it constantly deoptimizes.
Thank you for your watchful eye 😃

Good catch, indeed that one should be profiled instead.

Damn, I see that I failed at copy-pasting. The above links were not meant to be identical ;). The second example is this: 1fdc645#diff-0631793139d5299a8e27ab21a2b2880aR93