<headius>
really just annoying but gets in the way of doing git things after a build
<enebo[m]>
had a bogus comment in there
<headius>
solid numbers
<headius>
I can use this
<enebo[m]>
activejob has lots of bigdecimal errors unless I put a require in there
<enebo[m]>
Something is going it in MRI but not for us. Without knowing why I don't know if this is our problem or Rails
<enebo[m]>
so activejob pretty much doesn't run without that require
<headius>
could be some library that depends on bigdecimal for them and not for us
<enebo[m]>
yeah it definitely could
<enebo[m]>
So another thing which would sweeten these numbers is hash ordering
<enebo[m]>
Of all of this the actiontext one is the strangest errors...it is making opening tags and not putting any closing tags
<enebo[m]>
Makes me think we are not executing something right in that case
<enebo[m]>
I was trying to repro the single failure in actionmailer it is kwargs + ... but thus far everything works
<headius>
I'm assembling my talk today
<headius>
after I settle this timeout thing
<enebo[m]>
That whole actionmailer chain is all combos of ... + kwargs + zsuper all the way down
<enebo[m]>
I cannot print anything out because nothing is accessible
<enebo[m]>
Pretty funny
<enebo[m]>
It is the only kwargs-related failure in all of Rails tests now
<headius>
well that is good
<enebo[m]>
zsuper is a huge pain
<headius>
some things never change
<headius>
surprise surprise, the new impl of timeout based on rbx version appears to be the fastest for us
<enebo[m]>
oh bleh...hahah this is aliasing send using ...
<enebo[m]>
hmm
<enebo[m]>
shoot. This is not fun at all
<enebo[m]>
if I add a Ruby method ahead of the native send one with (...) and try and assume kw state has been stripped...it hasn't
<enebo[m]>
So the act of passing the kwargs into the native method where the callsite is ... which implicitly means it splats means the native arg has to also understand this splat dynamic
<enebo[m]>
Although this might only be for send since it is like a unique type of call
<enebo[m]>
all native methods will strip callsite splat field in TC going in since we don't use it in native methods and the native methods may dispatch to Ruby
<enebo[m]>
send is a native method but we probably do not want send to strip anything since it is like a callsite of sorts itself
<enebo[m]>
I am only like 95% sure I totally understand this fully
<enebo[m]>
This does beg an interesting quesiton which will address after railsconf but our invokers should separate out kwargs when they actually accept them
<enebo[m]>
Something like popen(fd, redirect: bleg) I think should arity error if it is called like popen(fd, {redirect: bleg})
<enebo[m]>
We are too accepting and this is not really an important bug but all our native code assumes we just check last argument
<enebo[m]>
Ok. I am distracting us. I am going to jot a note about this
<headius>
ok
<headius>
ok timeout should be on the way, I've +1ed it and hopefully we can get a gem released soon
<headius>
I'm going to gather a complete set of arjdbc benchmarks on sqlite3 for the talk
<enebo[m]>
ok. I am done for today. I made some progress on this last kwargs issue but it will take some more digging
<headius>
ok cool... if you get a chance think through what the important points are to get across about JRuby and JRoR in 30 minutes... just looking for anything I shouldn't forget to mention
<headius>
I'll throw slides together on the plane most likely using existing material but I'm not worried about having enough content
<headius>
ok this is weird... the benchmark for create has similar numbers for rehearsal and actual
<headius>
unlike the update numbers that are 50x faster for actual
<headius>
so I dunno what to make of this
<headius>
kares: maybe you know why this is?
<headius>
I may convert these to IPS just so they are easier to consume
<enebo[m]>
headius: I recommend looking at mpls railsconf slides
<enebo[m]>
I believe we had a lot of good broad strokes there
<headius>
yeah was that 2019?
<enebo[m]>
I don't know if you would have time but getting rubygems up and measuring RSS like we did before on newest JVM would be a very interesting slide
<enebo[m]>
Especially if you compared to that railsconf which measured total memory
<enebo[m]>
The internal bookkeeping stuff for classloaders now is much better for one class ones
<enebo[m]>
That would probably be a rails 5.2 comparison for apples to apples
<enebo[m]>
If I remember we were using like 220M of heap but the RSS was like 1.5G and a bunch of that was empty class storage since I think they were reserving space for 4 classes per classloader by default
<headius>
enebo: probably won't have time for it... my fallback for those larger setup items is just to use the 2019 numbers with a caveat that we have not had a chance to re-run
<headius>
to be fair we really just got all this working to a reasonable level in the past couple weeks
<headius>
I am shocked by the indy gains on these AR benchmarks