<kares[m]>
okay, not sure I will be able to that many experiments - well maybe on nights I can do a few restarts but not much during day/peak time :)
<kares[m]>
enebo: so you would auto increase the delta as time goes by for the app?
shellac has quit [Quit: Computer has gone to sleep.]
shellac has joined #jruby
<enebo[m]>
kares: I don't think so? I think the right delta should capture hotter methods as time goes by. The aging out of unused or no longer hot methods ultimately should be a second part of this but I don't think it will matter too much other than removing some early boot up methods
<enebo[m]>
kares: today I am going to try and set up some more reasonable tests to see if I can find a number where we stay the same in all cases but compile less
<headius[m]>
g'day
jrafanie has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
jrafanie has joined #jruby
dopplergange has quit [Ping timeout: 258 seconds]
shellac has quit [Ping timeout: 250 seconds]
xardion has quit [Remote host closed the connection]
xardion has joined #jruby
subbu is now known as subbu|lunch
sagax has quit [Quit: Konversation terminated!]
sagax has joined #jruby
subbu|lunch is now known as subbu
jrafanie has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<headius[m]>
kares: Have you run your JIT branch on that big app?
<headius[m]>
I'm doing a quick review...most of it's fine, just a few questions
<headius[m]>
Also a thought occurs about bytecode size... the way the JIT does method calls without indy right now is to emit a static stub that handles initializing the call site object and doing the call
<headius[m]>
the intent was to move as much code as possible for calling a method outside of the caller's body, but it's possible that's putting a lot of load on metaspace (so many static methods)
<headius[m]>
on the other hand I'm not sure if we want to just move that logic back into the bodies
<headius[m]>
we really need to explore a middle-ground indy call site that doesn't do the heavyweight binding but optimizes the creation and binding of the call site
<headius[m]>
constantly checking if the call site is initialized has to have a cost
<headius[m]>
note every call site in the system will do this check/initialize dance without indy enabled, where with indy it would create the site once and
<headius[m]>
hmmm
<headius[m]>
occurs to me now I could just use indy to initialize it
<headius[m]>
might be no more expensive than this and then look like a constant
drbobbeaty has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
lucasb has quit [Quit: Connection closed for inactivity]
<headius[m]>
yeah that's much cleaner
<headius[m]>
enebo: this might be working better than expected
<headius[m]>
maybe this is part of a road toward tiered indy rather than just off or on
<headius[m]>
this is very similar to just having an indy call site create and use one of our CachingCallSite
<headius[m]>
really would be additional overhead to also pass in the arguments to the call
<headius[m]>
I updated that gist...basically just eliminates the static field check+init dance in favor of an indy ConstantCallSite like lambdas use
<headius[m]>
so half as much bytecode for every call site that jits
<headius[m]>
but indy
jrafanie has joined #jruby
<headius[m]>
🤷♂️
<headius[m]>
it seems faster than the dance
jrafanie has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]