<headius>
kares: I have not seen it since and only saw it on CI
<headius>
the * characters make that build a bit noisy now though
<kares>
np if you remove them - just wanted to see progress to not give the impression that its stucked
<kares>
what is the hold up with 9.2.6 any eta?
<kares>
asking since I will need the 'less' thread sync issue in a release
<kares>
its blocking an update and since 9.1.17 doesn't have it either ...
<enebo>
kares: I was hoping to see a new rb-inotify come out but I think we can release today since there is a work around (user older rb-inotify for now)
<enebo>
kares: but that issue with rb-inotify will make all rails users see big stack traces at the end of every rails command they run
<enebo>
kares: actually maybe we should wait until Monday since kristian has not looked at tokari.io thing. I don't think there is any issue but those have been failing a while so for I know this finalization stuff we changed could effect those jobs
<enebo>
especially since they have embedding use cases in them
<headius>
kares: hey we need to discuss builtins
<headius>
it seems pretty solid now in my testing and I confirmed bootsnap works properly
<headius>
you had concerns?
<enebo>
headius: I did not see anything major and kares seems to have more opinion on it
lucasb has quit [Quit: Connection closed for inactivity]
<headius>
enebo: I expect we'll look at a 9.2.7 around end of month anyway
<headius>
ideally three releases (including 9.2.6) before RailsConf
<enebo>
headius: yeah maybe a tad sooner if alll the issues get ticked off
<enebo>
headius: but we need to do a rails test pass so we maybe will find more significant issues too
<headius>
could do more than 3 but you and I both have kaigi (probably)
<enebo>
yep
<headius>
enebo: you are ok with no_builtins in 9.2.6 then
<enebo>
I don't really expect basic Rails 6 greening work to extend past Feb
<enebo>
headius: no I think 9.2.7 is fine
<headius>
oh well ok then
<headius>
what is left for 9.2.6?
<enebo>
nothing
<enebo>
which is why I don't want to add anything
<enebo>
the monday is to just make sure kristian does not notice anything with finalization and hopefully rb-inotify puts out a release by then
<headius>
wrong type of warning for me to test, since it uses the AST directly, but it's obviously broken
aqd has joined #jruby
<enebo>
headius: oh interesting yeah I do recall something with warning/warn we changed a couple of months ago
<enebo>
some of that was from weirdness in how MRI warned in END blocks?
<enebo>
I can look a lttle bit after lunch...
<headius>
enebo: I have the warning partial trace change ready to go
<headius>
enebo: in that case it looks like the FixnumNode at that point has a source position with a null file
<enebo>
headius: yeah our Main/Ruby.parse paths depend on null in some ways and not others. A bit messy so I think when we changed impl of warn/warning something broke
<enebo>
I somewhat feel like "-e" should be the file to parse so that is confusing
<headius>
I was annoyed that my warning fix helped so little and then I tried bumping up the size of the stack
<headius>
100k iterations of a 100-deep stack triggering a warning takes 28s on Java 8, 3.2s on Java 11
<headius>
and 100 is pretty modest
<headius>
that's 100 ruby frames
<enebo>
is there a comparison with full frame processing?
<headius>
oh, and compiled to JVM bytecode...so it might be even worse in interpreter
<headius>
enebo: that's the 28s
<headius>
it has to dump the full Java trace just to dig out one Ruby stack element
<enebo>
oh you mean 8 because it does not have lazy processing
<headius>
right
<enebo>
ok
<enebo>
well that seems impressive
<enebo>
if you drop it to like 20 does it get a lot lower?
<enebo>
I am not suggesting it but I am wondering how much better it can get
<headius>
enebo: objection to push to master?
<headius>
drop what to 20?
<enebo>
max frames
<headius>
oh well the difference with only one level (warning-triggered method called in the main benchmark loop) is about 15-20% faster
<headius>
the deeper it gets from there just increases the time on 8 and stays the same on 9+
<headius>
can you think of anywhere else we need to use stack walking to just get nearest element?
<headius>
I feel like there's another case I'm forgetting
<enebo>
hmm
<enebo>
I don't know I don't think so
<headius>
I did Kernel#__dir__ and internal warnings test ed with [].index(1){}
<headius>
no idea how common __dir__ is in any hot path code
lucasb has joined #jruby
<headius>
FWIW it's still much slower than MRI because they have the caller stack frame in hand
<headius>
I need to profile to see whether we can trim more off that
subbu is now known as subbu|lunch
<headius>
enebo: remaining overhead mostly seems to be within the stack walking API...at least judging by allocations
<headius>
might be possible to trim it down by more direct usage of the API
<headius>
you ok with this on master then?
<headius>
stream API itself is creating a lot of this garbage 😳
<enebo>
java.io?
<enebo>
DARK MATTER
<enebo>
or you mean lambdas?
<headius>
the stack walking API uses Java 8 streams
<headius>
which apparently still have a lot of object churn internally
<headius>
I did have to run this against 10 because there's no jmc builds for 11 yet
<headius>
so they may have improved this in 11
subbu|lunch is now known as subbu
drbobbeaty has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
lucasb has quit [Quit: Connection closed for inactivity]