nirvdrum has joined #jruby
jrafanie has joined #jruby
<headius[m]> it wasn't actually our bug at all but it exposed some weaknesses in variable gathering
<headius[m]> I mean the race was our bug but they were causing it with code that's not safe anyway
jrafanie has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
jrafanie has joined #jruby
nirvdrum has quit [Ping timeout: 265 seconds]
travis-ci has joined #jruby
travis-ci has left #jruby [#jruby]
<travis-ci> jruby/jruby (master:90dce2a by Charles Oliver Nutter): The build was broken. https://travis-ci.org/jruby/jruby/builds/599439977 [197 min 30 sec]
Freaky has quit [Read error: Connection reset by peer]
Freaky has joined #jruby
jrafanie has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
_whitelogger has joined #jruby
_whitelogger has joined #jruby
rusk has joined #jruby
<olleolleolle[m]> @headius This upcoming Feature in the bug tracker of Ruby is interesting - "Make `monitor.rb` built-in"
<olleolleolle[m]> Seems like ko1 turns `monitor.rb` into a Ruby extension library.
<olleolleolle[m]> @head
<olleolleolle[m]> * @headius I noted this, because the same code was updated in the "get latest Ruby stdlib code in JRuby".
shellac has joined #jruby
Antiarc has quit [Ping timeout: 250 seconds]
shellac has quit [Quit: Computer has gone to sleep.]
shellac has joined #jruby
<kares[m]> olleolleolle: makes sense ... think JRuby is fine for now,
<kares[m]> unless ppl start using the 'internal' Monitor::Thread
<kares[m]> hmm, actually its Thread::Monitor so it might be public API in the end ...
<kares[m]> btw. what is the context - do not see that commit upstream, yet
<kares[m]> maybe this is just for 2.7 or is it to be commited to 2.5/2.6 lines?
<kares[m]> headius: been following - the hunch turns true - there's smt weird about the cast issue
<kares[m]> very nice and interesting as well, should we attempt to fix the .rb code?
<kares[m]> * very nice and interesting at the same time
<kares[m]> should we attempt to fix the .rb code?
shellac has quit [Quit: Computer has gone to sleep.]
shellac has joined #jruby
nirvdrum has joined #jruby
shellac has quit [Ping timeout: 265 seconds]
jrafanie has joined #jruby
lucasb has joined #jruby
<enebo[m]> ok this is pretty weird. Using headius PR I expected there to be less interpretercontexts set up but there is the same amount. We might be killing our method definiing laziness somewhere else as well.
<enebo[m]> OTOH we might not...I see ~10k ICs but 18k IRMethods and 3k IRClosure
<enebo[m]> I still expected a decrease though
<kares[m]> eeh nice - so it just walks the raw AST
<kares[m]> (to get the ivar names)
<kares[m]> enebo: almost half of loaded methods are lazy (not built) than?
<kares[m]> is this the PR branch or master
<kares[m]> on the inherited thingy - don't think I've seen it used the way http-cookie does
<kares[m]> using a class potentially immediately after inherited -> gem should get an update
<kares[m]> is there anyone we can ask (Aron, Yoko or @knu do have access) ?
<enebo[m]> kares: yeah original intent was that 87% of rails methods defined for a simple single controller app were not actually called
<kares[m]> * is there anyone we can ask (Aron, Yoko or @knu should have access) ?
<enebo[m]> kares: as it turns out for most large applications most methods in most libraries it is used are never actually called
<enebo[m]> kares: so 50% feels like too much has been accessed to me but perhaps it actually is. I did that analysis many years ago
<kares[m]> would not have guessed that to be that high but certainly >= 50%
<kares[m]> * would not have guessed that to be that high (for Rails) but certainly >= 50%
<enebo[m]> yeah I will audit where we end up creating the IC from AST and hopefully find something
<kares[m]> 👍️
shellac has joined #jruby
xardion has quit [Remote host closed the connection]
xardion has joined #jruby
nirvdrum has quit [Ping timeout: 245 seconds]
shellac has quit [Ping timeout: 240 seconds]
rusk has quit [Remote host closed the connection]
snickers has joined #jruby
Antiarc has joined #jruby
jrafanie has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
Antiarc has quit [Quit: ZNC 1.7.2+deb2ubuntu0.1 - https://znc.in]
Antiarc has joined #jruby
nirvdrum has joined #jruby
Antiarc has quit [Client Quit]
Antiarc has joined #jruby
subbu is now known as subbu|away
dcolebatch has joined #jruby
subbu|away is now known as subbu
nirvdrum has quit [Remote host closed the connection]
nirvdrum has joined #jruby
nirvdrum has quit [Remote host closed the connection]
nirvdrum has joined #jruby
nirvdrum has quit [Remote host closed the connection]
nirvdrum has joined #jruby
jrafanie has joined #jruby
nirvdrum has quit [Remote host closed the connection]
nirvdrum has joined #jruby
jrafanie has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
travis-ci has joined #jruby
<travis-ci> jruby/jruby (master:c376dd4 by Thomas E. Enebo): The build was broken. https://travis-ci.org/jruby/jruby/builds/599836171 [179 min 8 sec]
travis-ci has left #jruby [#jruby]
<enebo[m]> lulz...catch owned me...fixing
jrafanie has joined #jruby
jrafanie has quit [Client Quit]
snickers has quit [Quit: Textual IRC Client: www.textualapp.com]
travis-ci has joined #jruby
<travis-ci> jruby/jruby (master:ebab3d4 by Thomas E. Enebo): The build was fixed. https://travis-ci.org/jruby/jruby/builds/599861057 [203 min 26 sec]
travis-ci has left #jruby [#jruby]
<enebo[m]> yay...my first peephole opt is working locally too...I am just not gutsy enough to land it on friday and go to dinner :)
<enebo[m]> eqq -> btrue for when statements will elide the store + load
<headius[m]> Did you end up doing it in IR?
<enebo[m]> headius: it is in JVMVisitor
<headius[m]> Probably will be many other places we can use the same opt then, like the if/while cases I mentioned
<enebo[m]> yeah for sure
<enebo[m]> I think we will iterate a bit on the system as right now it is more or less assing nextInstr + a field for omitStoreLoad
<enebo[m]> but current visited instr + nextInstr feels fine to me without doing something drastic to visitor itself
<enebo[m]> Using a field for omitting stuff is probably a little less nice but that is why I think iterating may matter
<enebo[m]> for the primitive stuff I think that will end up being pretty clean as it is encoded in the operand itself
<enebo[m]> our actual visit methods will just call jvm{store,load} and it will do the right thing already
<enebo[m]> since you have that unboxing logic already
<headius[m]> Right, it is wired up to handle types
<headius[m]> Sounds good
<enebo[m]> yeah so just emitting the proper operand will be the only change and it will just work...I guess even nextInstr may not be needed
<headius[m]> I'm going to land the ivar fix...did you figure out why you didn't see fewer contexts?
<headius[m]> Was I wrong about it forcing them?
<enebo[m]> as I said yesterday I believe this will also require changes in how interp handles this but it is not a big change
<enebo[m]> sorry for some reason I don't get that question
<headius[m]> The interpreter contexts
<enebo[m]> oh I have not figured that out yet no
<headius[m]> You said above that my patch didn't seem to reduce them
<headius[m]> Ok I am curious then
<enebo[m]> well there was no change in number of ICs
<headius[m]> Right
<headius[m]> Seems like there should be
<enebo[m]> and when I look the only two things which will cause defnode to go away (and make an IC) is lazilyAcq and prepareForComp
<enebo[m]> yeah I agree seems like "something" is calling one of those two methods for some reason
<enebo[m]> I would guess lazilyAcquire but I stopped at this point and put it on a postit note :)
<headius[m]> I'll poke at that a bit this weekend after I fix mutex issue
<enebo[m]> funday friday was more about the peep
<headius[m]> Yeah cool
nirvdrum has quit [Ping timeout: 240 seconds]
dcolebatch has quit [Quit: On my way!]