<kares[m]>
* rtyler: there's a big gap between my level and the official JRuby core team 🤣
<kares[m]>
but what are you after ... research sounds vague - does it mean porting to JRuby? (eventually)
voloyev[m] has quit [Remote host closed the connection]
lopex[m] has quit [Remote host closed the connection]
OlleJonssonGitte has quit [Read error: Connection reset by peer]
MattPattersonGit has quit [Read error: Connection reset by peer]
rdubya[m] has quit [Read error: Connection reset by peer]
MarcinMielyskiGi has quit [Read error: Connection reset by peer]
olleolleolle[m] has quit [Remote host closed the connection]
CharlesOliverNut has quit [Read error: Connection reset by peer]
brometeo[m] has quit [Read error: Connection reset by peer]
TimGitter[m] has quit [Read error: Connection reset by peer]
ThomasEEneboGitt has quit [Remote host closed the connection]
liamwhiteGitter[ has quit [Remote host closed the connection]
enebo[m] has quit [Remote host closed the connection]
XavierNoriaGitte has quit [Read error: Connection reset by peer]
kares[m] has quit [Read error: Connection reset by peer]
KarolBucekGitter has quit [Read error: Connection reset by peer]
RomainManni-Buca has quit [Remote host closed the connection]
FlorianDoubletGi has quit [Read error: Connection reset by peer]
JulesIvanicGitte has quit [Remote host closed the connection]
TimGitter[m]1 has quit [Read error: Connection reset by peer]
headius[m] has quit [Read error: Connection reset by peer]
UweKuboschGitter has quit [Remote host closed the connection]
ChrisSeatonGitte has quit [Remote host closed the connection]
asp_ has quit [Write error: Connection reset by peer]
BlaneDabneyGitte has quit [Write error: Connection reset by peer]
justinbkay[m] has quit [Remote host closed the connection]
JesseChavezGitte has quit [Write error: Connection reset by peer]
kares[m] has joined #jruby
<kares[m]>
another interesting find from rdubya's app
<kares[m]>
at some point Rails likes to make sure AR model singleton classes exist
<kares[m]>
the app managed to trigger several of these from multiple threads and since addModule is synchronized it caused 44 distinct threads to wait for each other for a total of 31s (thread execution time). will put this into the tracker - easy fix switching the modules tracking collection to a ConcurrentWeakHashMap
rdubya[m] has joined #jruby
<rdubya[m]>
@kares nice find!
<kares[m]>
and I did not mention a few others (that are more minor) ... yet
<kares[m]>
... your app is so fruitful for JRuby! 🙂
enebo[m] has joined #jruby
<kares[m]>
* and I did not mention a few others (that are more minor) ... yet
<kares[m]>
... this Rails app is so fruitful for JRuby! 🙂
<kares[m]>
* another interesting find from rdubya's app
<kares[m]>
at some point Rails likes to make sure AR model singleton classes ...
<kares[m]>
the app managed to trigger several of these from multiple threads and since addModule is synchronized it caused 44 distinct threads to wait for each other for a total of 31s (thread execution time). will put this into the tracker - easy fix switching the modules tracking collection to a ConcurrentWeakHashMap
<kares[m]>
enebo: bit confused about CompiledIRMethod, thought that would only show up when inlining is enabled? MixedModeIRMethod is the one JIT compiles, also processes CompiledIRMethod for inlining. must be missing something here? (bit surprised to see them around)
<kares[m]>
* enebo: bit confused about CompiledIRMethod, thought that would only show up when inlining is enabled? MixedModeIRMethod is the one JIT compiles, while also processing CompiledIRMethod when inlining. must be missing something here? (bit surprised to see them around)
lopex[m] has joined #jruby
asp_ has joined #jruby
ThomasEEneboGitt has joined #jruby
FlorianDoubletGi has joined #jruby
JesseChavezGitte has joined #jruby
OlleJonssonGitte has joined #jruby
TimGitter[m] has joined #jruby
JulesIvanicGitte has joined #jruby
liamwhiteGitter[ has joined #jruby
MarcinMielyskiGi has joined #jruby
CharlesOliverNut has joined #jruby
XavierNoriaGitte has joined #jruby
headius[m] has joined #jruby
KarolBucekGitter has joined #jruby
MattPattersonGit has joined #jruby
justinbkay[m] has joined #jruby
ChrisSeatonGitte has joined #jruby
BlaneDabneyGitte has joined #jruby
olleolleolle[m] has joined #jruby
UweKuboschGitter has joined #jruby
voloyev[m] has joined #jruby
brometeo[m] has joined #jruby
RomainManni-Buca has joined #jruby
TimGitter[m]1 has joined #jruby
<kares[m]>
oh right its the end result on a compilation - silly me - makes sense now ...
<kares[m]>
somehow my brain thought jit ends up with a MethodHandle wrapper - should have looked
victori has quit [Excess Flood]
victori has joined #jruby
lucasb has joined #jruby
jrafanie has joined #jruby
shellac has quit [Quit: Computer has gone to sleep.]
jrafanie has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
jrafanie has joined #jruby
jrafanie has quit [Client Quit]
shellac has joined #jruby
<enebo[m]>
kares: also out main first script encounters is compiled and not mixed or interpreted (unless we disable compilation)
<enebo[m]>
@kares really interesting find with singletons
jrafanie has joined #jruby
jrafanie has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
lucasb has quit [Quit: Connection closed for inactivity]
joast has quit [Quit: Leaving.]
xardion has quit [Remote host closed the connection]
xardion has joined #jruby
joast has joined #jruby
<enebo[m]>
kares: when you say thread execution time of 31s do you mean wall clock waiting or cpu?
shellac has quit [Ping timeout: 250 seconds]
<rtyler>
kares[m]: not planning on porting to JRuby at this time
<kares[m]>
total blocked - waiting (for all threads)
<rtyler>
this is a fairly large Rails monolith we're working with primarily here, not clear whether JRuby would be beneficial
<kares[m]>
have another question - pbly MH related: why would a compiled method call lock its class-loader? the only explanation would be method-handles being involved, here's a sample:
<kares[m]>
* estimate of the total time threads were blocked by monitor
<kares[m]>
rtyler: okay than ... wasn't sure why you were tagging me
<kares[m]>
(if you need jruby help or smt)
<kares[m]>
out of the blue (curious), do you guys know who Karel Gott was?
<kares[m]>
lopex will know but otherwise if US folks actually heard of him ...
<rtyler>
kares[m]: I think highly of your experience on the application side of the stack, and was using you as an example of the type of hacker I'm looking for :)
subbu is now known as subbu|afk
subbu|afk is now known as subbu
<headius[m]>
That locking will be a good one to fix
<headius[m]>
it disables just about everything that's dynamic on a normal JVM, like right-size dynamic scopes and RubyObjects, JIT, JNR
<headius[m]>
other than actual JIT I think that can all be enabled with the right incantations
subbu is now known as subbu|away
<kares[m]>
oh - wow lots of work to make it useful ...
snickers has joined #jruby
<headius[m]>
I just force pushed with some comments about what changed
<headius[m]>
commenting was required because any bad code that's reachable will cause a naive native-image build to be rejected
<kares[m]>
* have another question - pbly MH related: why would a compiled method call lock its class-loader? the only explanation would be method-handles being involved, here's a sample: https://gist.github.com/kares/2e7fcffdc1f964f722977ee99e36270b
<headius[m]>
I think most of that could be put behind some "wall" that is not active when we're building a native image, and we slowly open up what goes in
<headius[m]>
really only the JIT and some advanced uses of method handles are a problem
<headius[m]>
I'm not going to push on that anymore for now. Going to look at stdlib update for 9.2.9
<kares[m]>
okay but will it ever be able to say boot up a web-server?
<headius[m]>
oh sure
<kares[m]>
even Rails in dev mode?
<headius[m]>
yes
<headius[m]>
the main problem is that anything you don't compile in becomes a hard fail at runtime
<headius[m]>
in the commit I show the command line you can use with graalvm to generate a list of all reflected classes
<enebo[m]>
kares: if you use nokogiri or oj or a native ext it needs to be compiled in
<kares[m]>
interesting
<headius[m]>
that would be enough to build in what you need as long as you exercise everything you need
<headius[m]>
in this case I just used it to make sure all the core classes were included in the image, since we set them up using reflection
<kares[m]>
okay so when I bundle update I would likely need an image rebuilt
<kares[m]>
* okay so when I bundle update I would likely need an image to be rebuilt
<headius[m]>
but for say puma, you'd include the puma http parser jar in classpath during native image build and it should get compiled in...then it's a matter of faking out the jar require
<headius[m]>
right
<headius[m]>
definitely would
<headius[m]>
this is something we would automate to death
<kares[m]>
got it now, thanks
<headius[m]>
bin/jruby-native rebuild
<headius[m]>
something like that
<headius[m]>
I should also mention the experiment there does not save a runtime on the heap (it could, and then just start running immediately) and it actually double-initializes
<kares[m]>
smt I wanted you guys to confirm about MH:
<kares[m]>
> have another question - pbly MH related: why would a compiled method call lock its class-loader? the only explanation would be method-handles being involved, here's a sample: https://gist.github.com/kares/2e7fcffdc1f964f722977ee99e36270b
<headius[m]>
so the 0.12s startup for -e 1 could be more like 0.01 if it cached a mostly-initialized runtime
<headius[m]>
and then beyond that, it could load in a bunch of Ruby and cache that in the native image...so imagine you have an image that's all set to run some command and the Ruby is already parsed into memory and maybe even pre-jitted
<headius[m]>
the fact that we can eagerly jit means we could eagerly jit the boot and stdlib libraries so they compile to native too
<headius[m]>
compiled method call as in CompiledIRMethod?
<headius[m]>
is this running with or without indy?
<headius[m]>
I mean "full" indy
<kares[m]>
yes
<kares[m]>
seems so - wout indy
<headius[m]>
ok
<headius[m]>
well there's one thing I can think of
<kares[m]>
this makes me worry about CL sharing a bit ... causing perf. regressions
<kares[m]>
but also I would like to understand the class-loader lock since I do not think we do that
<headius[m]>
CL locking should only be at define or load
<headius[m]>
should not affect the classes after that unless they interact with classloader more
<headius[m]>
what line of code do you think that corresponds to?
<headius[m]>
there's no line number
<kares[m]>
hmm, this has been from 2 threads - competing on the lock a bit
<kares[m]>
yeah I do not have lines really
<kares[m]>
but judging from the trace its a handle.invoke_exact call
<headius[m]>
kares: is that against 9.2.9?
<kares[m]>
9.2.8
<headius[m]>
ah
<headius[m]>
let me reinstall that quick
<headius[m]>
there's one place I remember doing a static lock for some logic