markov_twain has quit [Quit: markov_twain]
transfusion has quit [*.net *.split]
satyanash_alt has quit [*.net *.split]
satyanash has joined #jruby
transfusion has joined #jruby
subbu has joined #jruby
subbu has quit [Ping timeout: 240 seconds]
subbu has joined #jruby
markov_twain has joined #jruby
<byteit101[m]> headius: I don't see on mastodon if you are back or not from devnexus, but do let me know when I can have some help debugging the pipe read hanging issue on windows
markov_twain has quit [Quit: markov_twain]
<headius> I am back at work
<headius> trying to finish up some PRs so I can work on stuff for RailsConf
<headius> I can get my Windows VM up and have a look later today or tomorrow
<byteit101[m]> Whenever you have time
<byteit101[m]> I suspect that either a) Jruby leaks a handle, or b) the pipe code sets some flags weirdly, or c) I'm doing something wrong
<byteit101[m]> the most interesting thing is sometimes read(2) hangs when I know the pipe should have at least 3 bytes in it
<headius> ok what's the minimal repro right now?
* byteit101[m] chuckles
* byteit101[m] sighs
<byteit101[m]> A patched jruby that uses subspawn master on windows + this code:
<byteit101[m]> hangs on the x.read line
<byteit101[m]> (x.read or x.read(2) both hang with simialr frequencies)
<byteit101[m]> but only about 25-50% of the time
<headius> enebo: so I have a PR that adds arity checks to all IRubyObject[] methods, working through issues
<headius> it also removes arity-checking from the generated invokers so it's not being double-checked... but that led to an interesting question
<headius> third-party exts?
<headius> Logically they should also be checking arity in IRubyObject[] methods but up to now they could rely on the generated invokers doing that
<headius> a number of the failures I got on my PR were core methods that did not check arity themselves before and now caused ArrayIndexOutOfBounds because the invokers stopped checking
<headius> (mostly in tests expecting ArgumentError)
<headius> I guess the real question then is whether we remove the generated arity-checking or leave it there and accept double-checking when calling through DynamicMethod.call
<enebo[m]> headius: yeah you give a plausible possibility but it may not happen
<enebo[m]> headius: the other thought is only a fraction of calls will just be passing through random args arrays
<headius> yeah the main issue is that if an ext is not checking arity before blindly accessing args[] it will now be an AIOOB instead of an ArgumentError
<headius> but it would have been an error in any case before
<headius> all C exts obviously have to check because MRI does not do it for them
<enebo[m]> It is easier to be safe but I just don't grok how likely it is
<headius> I wish we could automate this but unless we rewrite the actual method bodies during build it needs a manual check
<headius> this did make obvious to me how much benefit we really get from arity-splitting and we should probably do a pass and split more stuff
<enebo[m]> you seeing a measurable speedup?
<headius> well it just made obvious to me how many arity checks we are doing when we don't split
<headius> we do no checks when we split because we know passed args matches required args
<headius> so it's free perf to split
<enebo[m]> yeah it makes sense I was just wondering if it sped up
<enebo[m]> The one place I do expect it to speed up is split paths to native calls since IR is forcing boxing of args more likely than not (until everything JITs)
<enebo[m]> only the caller side has to JIT to notice it
<enebo[m]> (with native)
<headius> yeah true
<headius> IR does split a few arity calls but I think only single arg cases
<headius> here's the PR... it looks green now after a few iterations: https://github.com/jruby/jruby/pull/7751
<headius> there's one failure in StringIO which I'll have to patch separately (no longer raises ArgumentError when it should, so one test fails
<byteit101[m]> hmm... how can I send a ctrl-c, kill 'int' isn't implemented yet, and shelling out to a utility kills the jruby launcher but not the jvm
<headius> ah yeah, enebo are we still only shipping a 32-bit jruby.exe?
<headius> byteit101: kill 'int' isn't implemented?
<byteit101[m]> NotImplementedError: this signal not yet implemented in windows
<byteit101[m]> kill at org/jruby/RubyProcess.java:1544
<byteit101[m]> kill at org/jruby/RubyProcess.java:1465
<headius> oh I see... I forgot that signal logic is a bit different on Windows
<headius> enebo: do you think we could do a 9.4.3 early next week for RailsConf?
<headius> byteit101: I'm not sure then... if you can get the real pid of JRuby an external call should work
<headius> with a 32-bit launcher and 64-bit JDK we have to launch a subprocess rather than keeping it all in the launcher pid
<byteit101[m]> I'm trying to fix read hanging, so don't really want to do a puts +gets as that might hang the process that gives me stats
<byteit101[m]> oh threads may work though
<headius> ah yeah try that for now
<headius> we should figure out why kill int has not been implemented on Windows
<headius> I forget now
<byteit101[m]> Errno::EBADF: Bad file descriptor - No message available... (full message at <https://libera.ems.host/_matrix/media/v3/download/libera.chat/a2b5d68e6586fa6463973e6b04352ce2b1b9df38>)
<byteit101[m]> Why no message available?
<byteit101[m]> is that expected?
subbu has quit [Ping timeout: 240 seconds]
<byteit101[m]> but yeah, it hangs in the read about 20-30% of the time
<enebo[m]> headius: perhaps but we have a few marked things which have to get fixed
<enebo[m]> The other question is what is the motivation to get it out
<headius> I need to review but I believe there were a few user bugs with no workarounds
<headius> it could also be the week of RC but I will be around less to help (still can do release tasks though)
<headius> if all we have to do is release that would be fine
<headius> gives us another week to finalize
<headius> arity changes and GHA speed improvements are landed
<headius> now I can get back to the PR that drove me to this (because I wanted more indy testing without adding a lot more time to CI)