<FarazYashar[m]>
Hey headius and ahorek : just want to say thanks for your help. Xorcist update is out.
subbu has joined #jruby
<headius>
that's great, thanks for your patience with the loader change!
<headius>
puritylake: not surprising... I don't think we have tried testing master on Windows at all yet
<enebo[m]>
headius: yeah 9.3.7.0 maybe beginning of next week. There is already at least one other fix but that one will irritate people
<enebo[m]>
headius: I have one question on thread polling
<enebo[m]>
My mind thought that whenever we did a dyncall there was something which would handle interrupts occasionally
<enebo[m]>
If we have a loop which contains a dyncall in the body isn't that sufficient for interupt handling?
<enebo[m]>
If not then it is all ok to me since we want to be able to interrupt. If so then only the loops not containing a dyncall need this (although I also would ask the same question of block yielding as dyncalling)
<headius>
there are some places where we poll for events on call boundaries but it is not consistent
<headius>
IR does check on method entry (I think) and backward branches, but in this case the only calls in the body were to math operations that get optimized to direct calls
<headius>
math calls that never stored a result or made any other calls with the result, so there's no IR method entry or normal dyncall or backward branch in the body of the loop to trigger polling
<headius>
it's a contrived spec but we should not ignore thread events just because a loop does no other heavyweight calls... I am unsure how much impact this will actually be on Range#each usage
<headius>
enebo: I just pushed another fix that should get into 9.3.7.0 after review... $! should be cleared after each finalizer or they stack up causes
<enebo[m]>
ok then I think we should put these in loops
<enebo[m]>
since it future proofs against later optimizations removing them
<headius>
we probably should audit our polling so we are doing it exactly in the places we should
<headius>
if we make these loops in Ruby code it would probably eliminate the problem so mostly we need to audit Java logic and optimizations in JIT
<enebo[m]>
yeah
<enebo[m]>
I think finalizer fix looks ok to me
<enebo[m]>
I mean I guess since it is a finalizer I doubt anything was depending on catching the exception
<headius>
yeah it just warns you on CRuby and you can't capture it
<enebo[m]>
The only scenario I can think of is one embeded Ruby somehow expecting result of another but that would be rife with peril and probably crash if they tried to do anything with it
<headius>
we probably would have noticed this sooner if our GC ran on user threads like CRuby, since there would be a lingering $!
<headius>
yeah and we have already started moving toward embedding clearing $! when going back to Java for this reason
<headius>
this was a change you made, not sure why it is picking up the compile-time file now but this StaticScope version of it must be getting the reduced path