<headius>
lopex: yeah having some benchmarks against joni directly would be very helpful
<headius>
I have been meaning to set up CI runs for joni, jcodings, jnr that pull in JRuby and run some JRuby stuff but it's complicated
<lopex[m]>
hiya
<headius>
I also like enebo suggestion to take the boolean configs and split impls so once they're configured they're never checked again
<enebo[m]>
headius I have today off but if the ethon gem guy comes on I believe we are somehow calling a native method within new and that is resetting callInfo
<enebo[m]>
headius: it seems to be a very simple kwargs method and call to #new so the real think I can think of is calling a native ruby method which then causes callInfo to get reset because it is not marked keywords=true
<enebo[m]>
headius: only other possibility is somehow that thread is somehow being used by two things at the same time (like enters new and something else calls a method using the same TC)
<enebo[m]>
that should not happen though
<headius>
enebo: yeah I did not see anything obvious in the code path that his stack trace shows. It passes through the normal Class#new logic which is marked keywords=true. I'm hoping we can get a full stack trace to see if there's some interstitial code not shown in the stack. The simplest answer does seem to be that callInfo is getting reset somewhere along the way, or possibly that the call side is losing the proper callInfo flag due to some optimization
<headius>
pass or JIT (he claimed --dev also failed, but I wonder if it was passed to all child processes)
<headius>
I will keep working through other issues today and culling the punters
<enebo[m]>
headius: You could mark allocate as keywords=true
<headius>
it should be called directly and not affect any thread state
<enebo[m]>
I don't see how it could happen though
<enebo[m]>
the fact it is an ordinary class should mean none of this should happen
<headius>
yeah it is technically a Ruby method but it takes no arguments and makes no calls
<enebo[m]>
all I can think is some gem is native and doing something strange like holding a TC
<headius>
we need that full stack
<enebo[m]>
yeah
<headius>
if the stack looks ok then either the call or the arity check has to be screwed up somehow
<enebo[m]>
he provided a stack for it but it is nothing special. Exactly just calling into initialize from new and seeing kwarg as normal arg
<enebo[m]>
I perhaps am too focused her but it 100% looks like callInfo=0 between new and initialize
<enebo[m]>
one way to debug it would be to make any reset calls log what called it and have them run that build
<headius>
first thing I notice is that it's running with invokedynamic in JIT mode... you said this stiil fails with --dev but did you pass that in JRUBY_OPTS env var or just on command line?
<headius>
actually scratch that... it's in JIT mode but not full indy
<headius>
we were hoping to ensure this fails with JIT off before proceeding
<Ethan[m]1>
it seems to do the same thing with JRUBY_OPTS as with argv --dev
<headius>
can you get a full trace with --dev too please?
<headius>
and I assume you still can't reproduce locally
<Ethan[m]1>
this is reproducing on both my mac at home and on github's ubuntu CI
<headius>
oh good
<headius>
oh I see you have not been able to reduce it
<Ethan[m]1>
yeah. various things I have done to try to narrow things down, or to debug, just cause it to not raise an argumenterror. like, if I add a `puts` before the `Schema::Ref.new` ([here](https://github.com/notEthan/jsi/blob/5d1192ff/lib/jsi/schema/validation/ref.rb#L14)) then it doesn't bug; if I step through it in a debugger, nothing raised
<headius>
hmm
<Ethan[m]1>
I added backtrace with --dev + -Xbacktrace.style=full to the issue
<headius>
ok looking
<Ethan[m]1>
not sure if here would be more convenient but I didn't want to spam such a large thing
<headius>
nah this is good
<headius>
how can I reproduce locally
<headius>
I think it would just be easier if I can see the issue and put a JVM breakpoint inside JRuby itself
<Ethan[m]1>
I put a little script toward the top of the issue that uses bundler/inline to get the library at the relevant commit and a line of code that triggers the error
<headius>
oh nice, somehow I missed that this is the quick way to repro
<headius>
let me try something
<headius>
ok I'm in
<headius>
the keyword flags we need have definitely been cleared by the time we get to the arity error, which is why it thinks it's a second argument instead of kwargs
<headius>
but why
<headius>
just trying to find the right combination of breakpoints to find the place we're screwing up this flag
<headius>
I should be able to hunt this down with some clever breakpoints
<Ethan[m]1>
I think you are a ways outside where I have any knowledge (not done any java in 15 years or more) but if I can offer any help with the ruby side I am happy to
<headius>
yeah it's something internal... we mark a call as passing kwargs by setting a thread-local value, and then the receiver picks up that value and treats the last argument as kwargs... somewhere along the way this value is not getting set properly or getting cleared before the target initialize method
<headius>
it looks like it's correct in the compiled Ruby code so I'm trying to figure out where it's going wrong
<headius>
hmm
<headius>
it's not getting set right
<headius>
yeah this is weird
<headius>
it gets set and then seems to be immediately cleared
<enebo[m]>
headius: I should point out Java debugger can call Ruby methods to display in debugger and that will wipe callInfo
<enebo[m]>
So you may not be able to introspect values while debugging callInfo
<headius>
enebo: yeah I think I'm seeing that here
<headius>
I'll try to turn that off
<headius>
flag is fragile, I need to get back to passing it through
<enebo[m]>
yeah or if you know when it happens you can generate exception at that point aand print it
<headius>
have you tried to step through this?
<enebo[m]>
yeah if this continues to be a problem we will just need to sphaghetti stack callInfo
<enebo[m]>
no
<enebo[m]>
this was too clever in trying to minimize overhead without passing it to site
<enebo[m]>
moving back into the shadows
<headius>
right click debug values window and you can mute it
<headius>
enebo: I think it's picking up CALL_KEYWORD_EMPTY
<headius>
from a previous call
<headius>
I'm not sure what that flag is supposed to mean
<headius>
nor why it is propagated always
<headius>
enebo: yeah I don't think that flag can be handled like this
<headius>
it's getting drawn in from some previous call and marking this call as having empty keywords, so the kwargs logic return %undefined
<headius>
then when it gets to the arity check it sees %undefined and does not subtract one from arg count
<headius>
blammo
<headius>
removing that masking from setCallInfo allows Ethan example to run correctly
<headius>
but I don't understand the masking
<headius>
Ethan: I think we have this in hand
<headius>
there's comments in the code in question wondering whether it might propagate some kwarg info from a previous call and clearly that does happen