razetime has joined #jruby
razetime has quit [Quit: https://quassel-irc.org - Chat comfortably. Anywhere.]
<puritylake[m]> Are my Pull Requests ok to merge?
razetime has joined #jruby
razetime has quit [Ping timeout: 245 seconds]
razetime has joined #jruby
<headius> Good morning!
<headius> I'll do a quick review this morning but they're probably fine
JasonRogers[m] has quit [Quit: You have been kicked for being idle]
razetime has quit [Remote host closed the connection]
<headius> enebo: this one warrants a sooner than later so we should look at other items that should get in too:
<headius> the only workaround without the fix is to update to JDK 14 or higher
<headius> puritylake: the two time-related PRs just have minor changes and then we can merge
<headius> need minor changes I mean
<headius> enebo: need your thoughts on this one too: https://github.com/jruby/jruby/pull/7283
<puritylake[m]> Got some issues with running tests on windows
<puritylake[m]> SystemCallError
<puritylake[m]> * SystemCallError UNKOWN_CONSTANT
<puritylake[m]> * SystemCallError __UNKOWN_CONSTANT__
<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 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 after review... $! should be cleared after each finalizer or they stack up causes
<headius> (for bad finalizers that raise errors)
<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> hmm
<headius> guess I should have forced a CI run of that jar-dependencies PR after releasing
<headius> hopefully the original reporter can figure out what broke, but here's the revert PR for 9.3.7 if that doesn't happen in time
subbu has quit [Quit: Leaving]
<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
<headius> could still be a bug in jit you exposed
Guest95 has joined #jruby
Guest95 has quit [Client Quit]