gordea has quit [Quit: gordea]
razetime has joined #jruby
razetime has quit [Ping timeout: 260 seconds]
razetime has joined #jruby
<enebo[m]> byteit101: oh interesting. Another place where we deleted a scope thinking it could never be executed again
<byteit101[m]> oop :)
<enebo[m]> I have to look at your repro but that line is interpreterContext.getInstructions which would mean we null'd it out
<enebo[m]> byteit101: ah...irb
<byteit101[m]> Yup, both in IRB
<byteit101[m]> one while trying to report the other
<enebo[m]> So we maybe notice it is an eval and decide to not keep the original around but that begs a question how id decided to JIT
<enebo[m]> heh...I wonder how irb works :) The closure is within a scope and the closure is added dynamically to the scope but I imagine we examine and say "no closures we can remove" or something like that
<enebo[m]> This is not at the top of my list today but it is curious
<enebo[m]> ah so running theory is we run the block n times enough to JIT and when the closure JITs we will then have to JIT all parent scopes. The parent was marked as execute once and deleted it. So when it gets to the parent it explodes
<enebo[m]> 2022-11-28T09:35:49.270-06:00 [main] INFO MixedModeIRBlockBody : JIT failed; no full IR or no call protocol found in block: CLOSURE EVAL_CLOSURE_1[(irb):1]<startup>
<enebo[m]> => nil
<enebo[m]> Ok I lied.
<enebo[m]> 9.3 detects that it has been removed and does not allow the closure to JIT
subbu has joined #jruby
<byteit101[m]> "If closure jits we boom." fair enough wording
<byteit101[m]> :-D
<enebo[m]> There is followup work here but that is a reasonable check since it is not the first time we hit issues like this and it will get logged
<enebo[m]> It is obvious what is happening but not obvious how it got into the state.
subbu has quit [Ping timeout: 260 seconds]
<headius> Yo
<headius> My flight is delayed tonight, working on talk and catching up in here
<headius> Fix looks nice and simple
<enebo[m]> so mocha fails 4 tests and it looked like kwargs but it is in fact something we changed in generating backtraces
<enebo[m]> which is almost as unfun as solving kwargs bugs :)
<enebo[m]> but we did change backtraces for 9.4 and we pass on 9.3
<headius> Something we changed in back traces is causing an error?
<enebo[m]> the testing here gathers a bunch of blocks and then uses a name to define_method them
<enebo[m]> our backtrace finds the name of that defined method instead of the test method it is called from
<enebo[m]> I have not fully hit the reason here but MRI will give the test name as the first element and we will not
<enebo[m]> but I rankle when I see JRuby-specific stuff in code :)
<enebo[m]> They strip org.jruby from backtrace elements
<headius> So it is using caller or something?
<enebo[m]> that is not the issue but it makes me wonder what else could be happening
<enebo[m]> caller
<enebo[m]> def self.current; new(caller); end
<headius> Got it
<enebo[m]> I have not distilled this enough to know what is wrong but I am happy it was not kwargs
<headius> There was one change I remember to make arity errors show up in the method that was being called but I don't think that should affect this
<enebo[m]> the code we shipped has veered off so long ago
<headius> Have you isolated a test case?
<enebo[m]> No
<enebo[m]> funny I ripped out the test and made a mock and it was fine
<enebo[m]> So I have to actually use their testing infra to deduce what the testing code is doing
<enebo[m]> Actually this is icky too. It will make test/unit or minitest runnable thing and then run it
<enebo[m]> so each test is put into a new class which represents the framework it uses but derives from Mocha::TestCase then runs that
<enebo[m]> For all I know this is some artifact not in mocha at all munging out backtraces
razetime has quit [Quit: https://quassel-irc.org - Chat comfortably. Anywhere.]
subbu has joined #jruby
<enebo[m]> These are the sort of bugs I find pretty unimportant in the grand scheme of .0 but it is a popular gem and we fail 4 tests
<headius> If it worked before it's probably going to be an easy fix
<enebo[m]> oh but it did and didn't :)
<enebo[m]> It worked before but these are tests only run for 2.7+
<enebo[m]> So they may be something we never worked with
<enebo[m]> 9.3 just happens to avoid hitting these because it is not about warning on 2.7+ kwargs deprecating behavior
<enebo[m]> The issue
<headius> enebo: trying to run railsbench with indy mode and I hit that UndefinedValue thing
<enebo[m]> ok. try with --dev just to see if it goes away
<headius> it seems to work without indy
<enebo[m]> threshold=0 too?
<headius> no
<headius> all I did was run without indy and then run with indy
<enebo[m]> I am curious if this is fixed arity kwargs issue or something with indy I was not aware of
<enebo[m]> I am sure I have run various things with indy enabled but I guess it depends on what
<headius> we have several suites running both ways too
<enebo[m]> try threshold=0 and make sure it is not a generic issue
<enebo[m]> I know there is something from the mechanize bug
<enebo[m]> err whatever that web-driven project is
<headius> seems ok through first few iters
<headius> you added something to debug this no?
<enebo[m]> I have an operator which only in startup interp will print out live operand values as a debug op
<enebo[m]> It should not be too hard to compile those
<enebo[m]> cool
<enebo[m]> I mean cool in the sense it might be much less convoluted than the other report
<enebo[m]> this looks similar
<enebo[m]> It was not in initialize_copy but this clearly is some recv instr grabbing a value %undefined when it should not be doing that (or something similar)
<enebo[m]> I am going to look at what that is in active_support
<enebo[m]> dup is fairly primal. hopefully it is not some stuff @ivar holding it
<enebo[m]> activesupport 6?
<headius> 6.0.6 yes
<enebo[m]> ok yeah just wondering if this is kwargs how that works out
<enebo[m]> self.__callbacks = __callbacks.merge(name.to_sym => callbacks)
<headius> yeah it is fairly simple
<headius> merge did change in the last week or two
<enebo[m]> ok well it is dup'ing itself which sort of sucks
<enebo[m]> That means __callbacks is %undefined or something happening in dup is undefined
<enebo[m]> which is possible
<headius> I should be able to set a breakpoint on this undefined error and see what's on stack
<enebo[m]> So I would say __callbacks is %undefined
<enebo[m]> I do not see how __callbacks is ever initially set
<headius> it has a default empty hash
<enebo[m]> class_attribute :__callbacks, instance_writer: false, default: {}
<enebo[m]> err I missed default
<enebo[m]> so I wonder if this method is broken with kwargs
<headius> it's something in the dup
<enebo[m]> so the hash is ok up until that point?
<headius> at the stack level of merge both hashes are fine
<headius> # Replaces Java version for better caching
<headius> end
<headius> initialize_copy(original)
<headius> def initialize_dup(original)
<headius> oops
<headius> that's our pure-Ruby initialize_dup
<enebo[m]> yeah
<headius> by the time we get in there arg0 is %undefined
<enebo[m]> sites(context).initialize_dup.call(context, dup, dup, this);
<enebo[m]> so it is fine right there?
<headius> yes
<enebo[m]> heh...well that is alarming
<headius> all the way up until the jitted initialize_dup body is called
<enebo[m]> ah the JITTed one
<enebo[m]> I wonder if there is something very basic wrong with 1-arity JIT
<enebo[m]> I would think normal JIT should see it
<enebo[m]> ah but this is happening with indy
<headius> yeah wherever the call is setting up these incoming args it loses the hash
<headius> INVOKESTATIC org/jruby/ir/runtime/IRRuntimeHelpers.receiveSpecificArityKeywords (Lorg/jruby/runtime/ThreadContext;Lorg/jruby/parser/StaticScope;Lorg/jruby/runtime/builtin/IRubyObject;)Lorg/jruby/runtime/builtin/IRubyObject;
<headius> ASTORE 7
<headius> ASTORE 3
<headius> INVOKESTATIC org/jruby/ir/runtime/IRRuntimeHelpers.undefined ()Lorg/jruby/runtime/builtin/IRubyObject;
<headius> probably something in here
<headius> there's not much more in the bytecode
<headius> not sure why this would only affect indy
<enebo[m]> well it might not only affect indy
<enebo[m]> ReciveKeywordsInstr in JVMVisitor is my bet on an issue with specificArity
<headius> return hash.isEmpty() ? UNDEFINED : hash.dupFast(context);
<enebo[m]> where is that?
<headius> receiverSpecificArityKeywords
<headius> receive
<headius> looks like call info is getting set up as CALL_KEYWORD before this initialize_dup call
<enebo[m]> I believe the notion of this is that if you receive an empty hash it is not really a valid argument but an empty kwargs
<enebo[m]> which weirdly can happen to any call like 'Array.size(**hash)
<enebo[m]> so it ends up as 0 arity call
<enebo[m]> although we handle Ruby -> Ruby where it does not pass it
<enebo[m]> but native call to Ruby maybe?
<enebo[m]> I have always felt this is gross but with all that said I am a bit confused why UNDEFINED is there
<headius> yeah the callinfo state is not set up right perhaps
<enebo[m]> either it should be EMPTY kwargs in callInfo or that undefined is not right there
<enebo[m]> The big problem with this method is it only happens on JIT and only when fixed arity
<enebo[m]> so it is not uncommon but also not as predictably called...with that said I feel this has to happen a ton
<headius> hmmm
<enebo[m]> which means how we call it is the strange thing
<enebo[m]> You can just return hash.dupFast() as that last return and see if it stop exploding
<headius> yeah probably will
<enebo[m]> I am curious enough to see what breaks
<headius> trying it
<enebo[m]> for fixed arity this would only make sense if we eliminate a parameter from being valid
<enebo[m]> but recieve instrs are not littered with checks
<headius> it appears to be running
<headius> yeah it works now
<headius> non-indy run may be going through a different path here that isn't specific arity
<headius> a guess
<enebo[m]> One issue with this when I was working with it was I started from interp version of this method and tried to adapt it to specific arity
<headius> I see nothing in here that should change due to indy
<enebo[m]> but people did have a similar report with kwargs on that web-automation package
<enebo[m]> with just JIT
<headius> good news is that indy mode is avout 40% faster than non-indy on this silly bench
<enebo[m]> I am wondering if any pass of {} as last specific param is part of the cause
<enebo[m]> there may be another piece like some callInfo state setup?
<enebo[m]> so to hit that path it HAS to be CALL_KEYWORD meaning callsite sending set that value
<headius> right
<enebo[m]> any @JRubyMethod marked keywords will not flush callInfo
<headius> hmm
<headius> merge is just rest
<enebo[m]> So native calling Ruby could erroneously get it from a native keywords marked method which did not reset it
<headius> that goes into native dup which eventually calls initialize_dup in ruby
<enebo[m]> Some methods do want resetting and others want to forward
<enebo[m]> dup and initialize_copy are normal
<enebo[m]> Actually where is the main dup defined?
<enebo[m]> well for Hash it is there and no big deal
<enebo[m]> initializerdup is no big thing either
<headius> RubyBasicObject.dup eventually does the initialize_dup call
<headius> merge calls that
<headius> from Java
<enebo[m]> yeah but there are fixed arity no special stuff
<enebo[m]> and since they are dyn dispatch they should be wiping out callInfo
<enebo[m]> hmmm I wonder if AS overrides these
<headius> yjit seems to be faster on this
<headius> 3.1 without yjit is about equivalent
<enebo[m]> push that change out to a PR and see what blows up
<headius> oh wait nevermind
<headius> we are much faster with parallel GC again
<enebo[m]> hahah
<enebo[m]> even with 19?
<headius> it gets down faster than yjit a few iters but then regresses
<headius> I'll try 19
<headius> regression might be my machine throttling too
<enebo[m]> I think I disabled speedstep
<enebo[m]> orwhatever that thing is
<headius> yeah that would be helpful
<headius> enebo: ok I will push this in PR
<enebo[m]> cool...eating lunch
subbu has quit [Quit: Leaving]
subbu has joined #jruby
sagax has joined #jruby
subbu has quit [Ping timeout: 265 seconds]
subbu has joined #jruby
subbu has quit [Ping timeout: 260 seconds]