<rwilliams[m]>
headius: what time zone are you in currently?
<headius[m]>
currently, US central
<rwilliams[m]>
you're based in MN right?
<headius[m]>
yup me and enebo both
<rwilliams[m]>
I could do a suberb of Minneapolis
<headius[m]>
it's a nice area
<rwilliams[m]>
though the wheather would take some adjusting
<headius[m]>
Winters notwithstanding
<rwilliams[m]>
hah yeah
<rwilliams[m]>
When the company you're consulting for says they're gonna take you ice fishing.....
<headius[m]>
it's not so bad if you get used to mostly being inside from December through maybe March
<headius[m]>
I've never lived anywhere you could be outside year round
<rwilliams[m]>
I live in sacramento so anything below 40 is like death
<rwilliams[m]>
I don't really own a jacket
<rwilliams[m]>
well winter coat
<enebo[m]>
Some people adjust pretty quickly and others never feel warm again.
<headius[m]>
yeah bit of an adjustment but at least you're not in a really warm place
<rwilliams[m]>
Yeah i did a couple of trips to enden prairie in nov and early spring
<headius[m]>
weirdly we have large immigrant populations from Indochina and Somalia
<enebo[m]>
MN keeps getting warmer except for a 2 weeks in the winter where it gets much colder because the jet stream has been changing
<headius[m]>
yeah we always get a week below 0ºF
<headius[m]>
sometimes way below... was it down to -30 last year?
<enebo[m]>
warming climate has been pushing jet stream down so I think we get a little longer and a little colder...but only a little more than it used to be
<enebo[m]>
It also I think has been responsible for how much rain we have been getting in warmer months
<enebo[m]>
last year had most precipitation in our history
<rwilliams[m]>
wow
<rwilliams[m]>
We had great rain last year after probably 5 of so years of drought
<enebo[m]>
yeah get used to it
<enebo[m]>
CA will probably continue to dry out and you will be fighting water wars from your primary water source
<rwilliams[m]>
Yeah :(
<headius[m]>
we get a lot of work done during the winter
<enebo[m]>
hahaha
<headius[m]>
yeah Mad Max California Dreamin
<enebo[m]>
I used to be a more outdoors guy in winter...not any more
<rwilliams[m]>
The company i was working for used geothermal for their data centers during the winter, it was pretty cool
<rwilliams[m]>
for cooling
<headius[m]>
at least you won't be fighting over guzzoline once everyone's driving EVs
<rwilliams[m]>
Yeah
<rwilliams[m]>
I'm thining a model 3 for my next car
<enebo[m]>
I have owned a nissan leaf since 2015
<rwilliams[m]>
Nice
<headius[m]>
I'd get an EV for my next car but I'd need to talk to my apartment about charging
<enebo[m]>
84 mile range sometimes hampers me but any new EV has way more than enough
<headius[m]>
someone's going to breach that question soon enough though
<enebo[m]>
I prefer a proper hatchback so I think even the model Y is off the table
<enebo[m]>
plus I dislike the ipad only interface of 3+
<rwilliams[m]>
enebo: I was looking at the egolf a few years back but i regularly drive 90 ish mile round trips so it would be a pain
<enebo[m]>
headius: yeah that is something places like NL has figured out but it will have to happen soon
<enebo[m]>
rwilliams: yeah Tesla is a great choice with supercharger. ID.3 by VW when it comes out will have the range but charging in US "depends". CA probably is fine for non-Teslas too
<enebo[m]>
ID.3 will kill it in europe
<enebo[m]>
It should do well in US too but EU loves their hatchbacks
<rwilliams[m]>
oh that looks nice
shellac has joined #jruby
<rwilliams[m]>
i dig smallish cars
<rwilliams[m]>
I had a gti and golf r previously
<headius[m]>
EV does worry me because I take 2-3 long driving trips in summer
<headius[m]>
I could rent but meh
<enebo[m]>
Tesla model Y I think is compromising range via aero to have proper hatch size
<enebo[m]>
yeah renting is a good choice though for long road trips since you do not put that wear on your car
<enebo[m]>
priced out it may be similar costwise but it drags out when you need to make that next big purchase
<headius[m]>
hard to know whether the wear is worth it for renting a car for a week just to drive to and from a place though
<headius[m]>
seven days of rental to save 20h of driving wear on my car
<enebo[m]>
20h of driving is how much normal driving? 3-4 weeks?
<headius[m]>
I'd say more like 2 with kid stuff
<headius[m]>
maybe less
<headius[m]>
I drive to Fridley for pool every week
<headius[m]>
yeah I'd say I easily do 10h a week
<rwilliams[m]>
pool like swimming or pool like billiards?
<headius[m]>
which is weird since I don't commute
<headius[m]>
pool like billiards, I'm in an APA league for 8 and 9-ball
<rwilliams[m]>
oh cool
<enebo[m]>
yeah at highways speeds that would be 600+ miles
<headius[m]>
enebo: almost have IRBytecodeAdapters busted up into smaller interfaces
<headius[m]>
makes it pretty clear what stuff is indy-always now
<headius[m]>
I'll restore the non-indy versions from before recent bytecode optimization
<headius[m]>
should be possible by end of day to have AOT emit code with no invokedynamic
<headius[m]>
well hopefully way before end of day
<headius[m]>
I dunno if this is the "best" structure but it will let us compile things separately... how we compile literal values vs invocations vs yields etc
<enebo[m]>
ok well we can play with this. I also have needs of wanting to call different things for inliner
<headius[m]>
yeah that can be another form of the InvocationCompiler
<enebo[m]>
like being able to produce a different callsite and use indy for post-inlined versions
<headius[m]>
should be able to just implement invokes and reconfigure
<enebo[m]>
but it is likely a dimensionality aspect as well...AOT with inlining vs JIT with inlining
<enebo[m]>
anyways I will see how you changed things today :)
<rwilliams[m]>
So will we be able to have ruby/rails/and our gems AOT'd for development so startup should be super fast? when this all gets going.
<enebo[m]>
well it our hope that it will be faster
<enebo[m]>
headius: this is still one huge outstanding question...why if I run more rails commands does rails console get slower?
<enebo[m]>
at most it should just mean more files are in ~/.ir but the same number of them should get consumed running rails console whether they are more files or not
<enebo[m]>
The more I think about this the more it bothers me because the speed difference is large
<enebo[m]>
CLASSPATH= the issue? is Java scanning all that whether it is used or not?
<headius[m]>
could you try jarring them up?
<enebo[m]>
sure I can give that a go
<headius[m]>
the way I'm loading the script classes, I check first if they are actually there as a .class file using getResource
den_d has quit []
<enebo[m]>
So after running runner I have 1704 .class files
<headius[m]>
to avoid hitting ClassNotFound for everything when nothing's compiled
den_d has joined #jruby
<enebo[m]>
runner will rails new; scaffold migrate, server
<headius[m]>
I dunno if that or classloading are sensitive to the number of files
Iambchop has quit []
<enebo[m]>
I am seeing nothing with -d but would I?
Iambchop has joined #jruby
<enebo[m]>
Are we eating that exception somewhere?
<headius[m]>
JVM6/7, ClassData6/7, and IRBytecodeAdapter6/7 are gone!
<headius[m]>
huzzah
<enebo[m]>
ok well I think I am excited but I am not sure yet :)
<headius[m]>
you can see tryScriptFromClass in Ruby
<headius[m]>
only exception it catches is CNFE and logging will output something
<headius[m]>
but really now you shouldn't see it since I check if the resource is there
<headius[m]>
there's no other fast way to say "try to load this class" unfortunately
<enebo[m]>
time echo exit | CLASSPATH=/home/enebo/a.jar JRUBY_OPTS="-Xcompile.cache.classes=true --dev -J-XX:+UseParallelGC" jruby -S rails c
<headius[m]>
if you have more classes but don't reference them I don't know why it would be slower
<enebo[m]>
If I do this it complains: LoadError: load error: rails/cli -- java.lang.NullPointerException: null
<enebo[m]>
but I went into ~/.ir and did a jar cf ../a.jar .
<headius[m]>
pushed changes
<enebo[m]>
should I have did that from home?
<enebo[m]>
ignore me
<enebo[m]>
I changed dir :)
<headius[m]>
I want to see NPE
<enebo[m]>
ok doing that second after I go into an actual ruby dif
<enebo[m]>
err rails
<headius[m]>
making jar in .ir should work
<enebo[m]>
ok working
<enebo[m]>
same speed as .jar
<enebo[m]>
This might be because I do not have your synch. commit
<enebo[m]>
I cannot repro now
<headius[m]>
I did not dig deeper on that so I don't know what was causing it exactly
<headius[m]>
same speed as in you see slower than just generating rails c classes
<enebo[m]>
same speed using cache classes in ~/.ir or in a jar
<enebo[m]>
how do I do appcds?
<headius[m]>
it's in the gist I made yesterday
<enebo[m]>
not really related unless it massively changes this
<headius[m]>
if both modes load the same classes I'm stumped
<enebo[m]>
well of course with what I showed you they will not
<headius[m]>
seems fine
<headius[m]>
what do you mean?
<enebo[m]>
one only does the first ruby process of running that command and the second one does both
<enebo[m]>
so it is a massive difference in number of classes loaded
<headius[m]>
for emitting AOT
<headius[m]>
but for rails c I want to see what classes actually load
<headius[m]>
there shouldn't be any difference regardless of how much you AOT
<enebo[m]>
I missed in second section but in second run it generates 1421 classes
<enebo[m]>
first is only 134
<headius[m]>
ugh I have to write constant lookup logic without indy...that has never existed in 9k
<headius[m]>
not generate
<headius[m]>
load
<headius[m]>
only 134 files AOT if you just dump for rails c? That seems really low
<enebo[m]>
well I fully expect the difference to be 134 vs 1421 but I can see if those both end up being the same amount of loads or not as were generated
<enebo[m]>
I must have not written that gist clearly
<headius[m]>
the rails c case that only touches 134 scripts should definitely NOT be loading 1421 classes
<headius[m]>
your runner causes a lot more files to load and AOT
<headius[m]>
that should not change how many cached AOT classes are loaded by rails c
<enebo[m]>
hey let me try this again
<enebo[m]>
one I put -X+C into main command and in the other I put it in JRUBY_OPTS
<headius[m]>
yup
<enebo[m]>
I did this so second spawn of Rails in rails console would not pre-cache those
<enebo[m]>
that second spawn loads a lot more code than the first
<headius[m]>
oh
<enebo[m]>
which is why we only see 134 class files vs 1421
<headius[m]>
well that's the reason right there
<headius[m]>
most of the rails c scripts aren't actually loading from classes then
<enebo[m]>
but only doing 134 made it start up noticeably faste than --dev without it
<headius[m]>
that's why it's faster
<enebo[m]>
but it is still faster than --dev
<headius[m]>
ok
<headius[m]>
ok I think I follow
<enebo[m]>
that was my wonderment...it is clear that cloassloading can take longer than --dev
<enebo[m]>
but some classloading did pay off
<headius[m]>
so caching AOT for just the first-process Rails scripts makes rails c start up faster
<headius[m]>
caching AOT for both first and second does not help
<enebo[m]>
yeah considerably faster
<headius[m]>
so something compiled for that first set is actually helping and something in the second set is hurting
<enebo[m]>
So your work right now may pay larger dividends if the cost of the slowdown is indy on classes/modules/scripts
<enebo[m]>
it should help code interp so I expect the full case to improve on timings
<enebo[m]>
and currently it is approx even with --dev
<headius[m]>
that's interesting
<headius[m]>
I wish there were a way to force rails to not spawn
<headius[m]>
even -v spawns now I think
<headius[m]>
ok I believe you
<headius[m]>
I can try to repro that now that I understand
<headius[m]>
I thought you were always using env but the runner case was also emitting AOT for stuff like generating app
<enebo[m]>
I was yesterday...I swear...but with these results I do have doubts now
<headius[m]>
so rails c full AOT is that 1400-some count and something in that extra 1200+ seems to be negating the gains from the initial 134
<enebo[m]>
yeah
<enebo[m]>
our best hope is modules/scripts/classes are slower and not using indy will be a lion share
<enebo[m]>
we need guided dumps
rusk has quit [Remote host closed the connection]
<headius[m]>
yeah so interesting facts..
<headius[m]>
parent rails process only loads 134ish scripts, which is remarkable
<headius[m]>
once loaded it will futz around with bundler and dependency stuff and then respawn
<headius[m]>
so that logic might not have jitted before and remained interpreted and slow every time
<headius[m]>
now it's already bytecode so that plus Tier=1 improves the speed of the parent launch
<headius[m]>
child process loads ALL of rails and app and then just starts up console
<headius[m]>
so most stuff doesn't execute more than running through the script most likely
<enebo[m]>
yeah I was not sure how much of railties loaded but I assumed most of rails was not in first process
<headius[m]>
right
<enebo[m]>
1421 scripts seems massive to me
<headius[m]>
so fewer classes, fewer methods
<enebo[m]>
but helpful
<enebo[m]>
we know they will get loaded in second run
<enebo[m]>
so both runs do them
<enebo[m]>
which might be part of it
<headius[m]>
I will have almost everything non-indy shortly
<headius[m]>
constants will take longer
<enebo[m]>
but it underscores loading from AOT is slower than parsing
<headius[m]>
because I have to make that code up
<headius[m]>
right, so lower to load (ignoring CDS etc) but potentially we're seeing warmup kick in faster
<headius[m]>
you could get jit logs for the two cases, just for top process
<enebo[m]>
yeah my take as well
<headius[m]>
two cases = --dev with and without cache
<headius[m]>
if we see more ruby methods JIT by JVM we may have an answer
<headius[m]>
a good answer for FOSDEM Too
<headius[m]>
I realize my splitting up of JIT stuff is not quite what we want
<headius[m]>
we want things that run for the script body to be non-indy in probably all cases
<headius[m]>
but anything in repeatable bodies should usually be indy except if we're AOTing for non-indy environment
<headius[m]>
the split is clearly things that run once versus things that run many times
<headius[m]>
this is also something that might justify only emitting AOT for repeatable bodies and leaving script's once-through as interpreter
<headius[m]>
justification for AOT emitting per-method but your 1400 classes will be more like 14000 then
nirvdrum has quit [Ping timeout: 268 seconds]
<headius[m]>
dear god I need that new MBP just for the blasted arrow keys
<enebo[m]>
so I was thinking the same thing with saving interp'd version of scripts/module/bodies which do not contain anything other than defs
<enebo[m]>
we could actually do ruby rewriting and emit smoething without comments
<enebo[m]>
heh just thinking about making a mega simple interpreter which just knows how to call constructors which represent compiled methods or interpreted class bodies also in the same interpreted language
<enebo[m]>
the language would be tiny
<headius[m]>
yeah
<headius[m]>
these are definitely very different targets
<enebo[m]>
oh wow...I just realized there is some very interesting potential
<enebo[m]>
script -> module -> class -> method1, .... method n
<enebo[m]>
the script/module/class could all literalls just be in the same "script" and not nested at all
<enebo[m]>
so that structure could just be serialized
shellac has joined #jruby
<enebo[m]>
if there is other logic...then well it is ruby but most ruby classes are literally just mild nesting with methods defined in them
<headius[m]>
well this kinda plays into the codeDB idea Brian was working on
<headius[m]>
or at least I think it does...basically if we can separate the structure of what a script defines from the little bits of code it runs we can do a better job of loading up that structure quickly
<enebo[m]>
well it would be a different form...but I think this is more akin to just having a better serialized format than Ruby or IR
<headius[m]>
I mean a large portion of the code in script+module+class bodies is nothing but defining things
<enebo[m]>
main problem with Ruby parser is it is really big
<enebo[m]>
ah yeah that is true
<enebo[m]>
I would say nearly all of it is
<headius[m]>
but at the very least anything we should have a lighter-weight execution mode for any scope that's not a method, block, or metaclass inside method or block
<enebo[m]>
There are some libraries which have lots of top-level logic but once within a class it just goes normal again
<enebo[m]>
The other major legs this has is the notion that we are not polluting all thes one-time types
<enebo[m]>
Java types I mean in this case
<enebo[m]>
So main premise is Ruby parser warms up slowly and JIT is just a really expensive way of doing this
<enebo[m]>
appcds is a hope for making JIT less expensive (I should say AOT here)
shellac has quit [Ping timeout: 248 seconds]
<enebo[m]>
but even if it was free we would use way less memory if we had a simple interp which threw that away immediately
<headius[m]>
yeah
<headius[m]>
so with the AOT the way it is now we're paying the high cost of loading and running script/module/class bodies exactly once
<enebo[m]>
Well we may have a new "futures" section
<headius[m]>
but also gaining a leap into already-compiled methods and blocks
<headius[m]>
we want the latter but not the former
<enebo[m]>
yeah exactly
<enebo[m]>
so one-time should construct those others in something which can warm very quickly
<enebo[m]>
but not add a java type
<enebo[m]>
I do realize one additional snag (not really a snag but important addition)
<enebo[m]>
require is a call at the top of most calls so this simpler interp still needs to address require as a call
<enebo[m]>
so class/module/def/require as valid elements and class/module can just emit into the same string its contents
<headius[m]>
I don't think calls in a script body need any special handling
<headius[m]>
oh but you are thinking of a Ruby subset for script body I guess?
<enebo[m]>
yeah completely different interp
<enebo[m]>
that is a loop which literally only knows how to do like 6 things
<headius[m]>
in theory that can work but I feel like most scripts will have at least one thing to break that
<headius[m]>
not only require but metaprogramming methods
<headius[m]>
attrs, aliases
<headius[m]>
define_method
<enebo[m]>
most? I don't think so but subscopes in those files won't and can use it
<enebo[m]>
it is not all or nothing
<enebo[m]>
I guess it would make me wonder how many would have to be that way to be worth it
<enebo[m]>
and also perhaps there are a handful of ruby builtin methods where they could be added
<enebo[m]>
attr_reader* and alias/alias_method
<headius[m]>
yeah I have nothing to back up my feeling
<headius[m]>
if I pick a file at random...
<enebo[m]>
I agree that there are many files which do but I bet there are many scopes which don't
<headius[m]>
find.rb is ok, needs module_function
<enebo[m]>
if it was 40% it likely would still be a big win
<headius[m]>
so those are there too, module_function, public, private, protected
<headius[m]>
and in 2.7 ruby2_keywords or whatever nonsense
<headius[m]>
forwardable assigns a class instance var
<jeremyevans>
headius[m]: ruby2_keywords isn't scoped like module_function, public, private, protected
<enebo[m]>
just looked in random activejob file
<headius[m]>
OpenURI builds a hash for a constant...hash could contain a lot of other stuff but it's all symbols and constant values here
<enebo[m]>
one require with a bunch of module/class nesting...one module has extend
<headius[m]>
so most of these have manageable needs
<jeremyevans>
headius[m]: assuming by scoped you mean when called without arguments, affects future methods
<enebo[m]>
but fcalls in any of these scopes would be trivial to add
<enebo[m]>
I think fcall so long as it is constant or immediate and stuff talked about above for scopes could be a very small interp
<headius[m]>
you could kind of figure this out right now by just compiling something with lazy method bodies then scan instrs
<headius[m]>
or just walk all scopes until you reach method or blocks
<headius[m]>
ignore those
<enebo[m]>
well I was thinking about what source elements must exist and just check in AST building
<headius[m]>
yeah I dunno how much smaller it is looking at things
<headius[m]>
like what wouldn't be in a script body?
<headius[m]>
all the literals are possible for constants
<headius[m]>
all forms of calls
<enebo[m]>
You know I am saying we only do this in the presence of limited set of elements
<enebo[m]>
if there are more than that then punt
<headius[m]>
sure, there may be a subset that's a win
<headius[m]>
clearly if it's only class, module, def, visibility methods, attrs, and requires that's one possible subset
<enebo[m]>
I think it will be pretty large but I guess I will have to analyze and probably try something
<headius[m]>
constants pull in all the literal types
<enebo[m]>
but the constant is its own interp element
<headius[m]>
everything I've looked at so far would need class, module, def, visibility, attr, and at least constant assignment for the class/module
<enebo[m]>
extend Foo is a interp of Foo and fcall on the result
<headius[m]>
we could also go back to AST interp just for script/module/class and only use IR for method/block bodies
<headius[m]>
how's that for nutso
<headius[m]>
99% of what runs at app boot would go through AST interp but methods and blocks would be IR and optimizable
<headius[m]>
NUTSO
<enebo[m]>
well I said that a while up above
<enebo[m]>
but I realized that if we are going to interp then we could choose how to interp
<enebo[m]>
a limited form for limited format files and ordinary for things not limited
<enebo[m]>
lunch be back in a bit
<headius[m]>
I didn't see you mention AST interp but yeah this is all interesting
<headius[m]>
I mean really CDS is basically codeDB because it caches the structure of class files
<enebo[m]>
oh haha I did not read that properly
<enebo[m]>
yeah that is nutso
<headius[m]>
shareclasses in OpenJ9 is the same thing...it pre-processes the metadata for classes into the internal VM format and saves that
<enebo[m]>
I mean if we make an AST interp we may as well just kill the IR interp
<enebo[m]>
which is always a possibility
<headius[m]>
so the general idea is being able to smartly build/understand the structure of a Ruby script without a full interp
<headius[m]>
rather than blindly interpreting it like any other piece of code
<enebo[m]>
ok my food is hot on the table...back in a few
<headius[m]>
yeah it's a possibility
nirvdrum has joined #jruby
<headius[m]>
HOT FOOD
<headius[m]>
ok
<headius[m]>
I should probably eat something other than coffee
<enebo[m]>
eat some coffee
<enebo[m]>
another detail is in simple module A { module B { class C { def ... } } } it would save it as a single linear stream and each nesting would push to some pre-calcd primitive and the interp would just be a single linear pass potentially not even saving to the array if the back side of each scope does nothing
<enebo[m]>
s/primitive/primitive array/
<enebo[m]>
which is most common scenario
<headius[m]>
sure
<enebo[m]>
but talking through this a bit I can see supporting limited Constant and Constant Set + fcalls would greatly expand what it could do
<enebo[m]>
the other great thing about this would be not standing up an AST
<enebo[m]>
It could even be protobuf
<headius[m]>
yeah
<enebo[m]>
At some point the balancing point would be more about how many scopes fit the limited description and how big the resulting interp is
<enebo[m]>
because tiny pre-inlined all temps would be ideal
<enebo[m]>
nesting of scopes likely means knowing whether we care or allocing a small array or pre-allocing one as some field
<enebo[m]>
anyways this is not for today :)
<enebo[m]>
I like the idea in as much as I believe I can reduce the whole thing to something which is faster to parse than the original Ruby
<enebo[m]>
and it still blows my mind that the Ruby parser is competitive after all these years
<enebo[m]>
If you look at stdlib about 50% is comments now...processing those are not free
<enebo[m]>
not expensive but even us having to revalidate every string eevn though it is the same ident as the previous 50 in a file
<enebo[m]>
just having a simple constant pool should make it a win
<headius[m]>
yeah that structure can be boiled down a lot more
<headius[m]>
try zing now
<headius[m]>
or get jit log from top-level rails process with and without cache
<headius[m]>
I almost have non-indy AOT done except for constants
<enebo[m]>
ok I got key and downloaded
<headius[m]>
non-indy constants shouldn't be hard if I just call what interp does
<headius[m]>
the other thing I realized about openj9 is that I don't know if it's bothering to compile and cache those once-through bodies
<headius[m]>
I'll ask J9 folks actually
<headius[m]>
enebo: I've pushed non-indy stuff I have so far
<enebo[m]>
cool
<headius[m]>
will look into constants now but you should try with latest
<headius[m]>
that's the last piece in JIT that still uses indy unconditionally, I believe
<enebo[m]>
ok I have zing installed now but I do not know what to do from there
<enebo[m]>
I will peruse their user guide
<headius[m]>
other than e.g. MethodHandle instances passed out to compiled block/method
<enebo[m]>
I will try your changes first thoguh
<headius[m]>
yeah you want the ReadyNow feature
<headius[m]>
I have never used it
<headius[m]>
hopefully it's as easy as J9
<enebo[m]>
I will just trying running this as is quick to see if it is faster/slower than hotspot
<headius[m]>
oy constant logic is bigger than I expected in interp
<headius[m]>
because it's caching
<enebo[m]>
heh --dev is slower than no flags
<enebo[m]>
Don't know how Zing deals with that
<headius[m]>
interesting
<enebo[m]>
doh I should probably not specify parallel either
<enebo[m]>
wonder if it just ignores stuff
<headius[m]>
J9 does
<headius[m]>
there's probably a separate set of flags that would be appropriate for --dev on zing
<headius[m]>
we can add to the uberlauncher
<headius[m]>
I need a break before I attempt and give up on non-indy constants
<enebo[m]>
so however --dev is getting interpreted it is slower than not specifying it
<enebo[m]>
removing parallel changed nothing at all
<enebo[m]>
cache on and off are the same speed
<headius[m]>
the biggest gain from --dev is tier 1 but it also turns off jit...maybe jit is more important on zing
<enebo[m]>
zing will make us never exit if I am doing this right
<enebo[m]>
ProfileLogOut will write info out
<enebo[m]>
ProfileLogIn will use that
<enebo[m]>
doing a ProfileLogOut will finish and make a file
<enebo[m]>
ProfileLogIn seemingly just does not exit
<headius[m]>
Make us never exit?
<headius[m]>
That's weird
<enebo[m]>
yeah very weird
<enebo[m]>
The docs are far from clear
<enebo[m]>
It does make an epic log file on report generation
<enebo[m]>
I think we have an issue with native gems and switching JVM above 9
<enebo[m]>
or 9+
<enebo[m]>
each time I switch it claims it cannot find bindex gem
<enebo[m]>
LoadError: Could not open library '/home/enebo/work/jruby/lib/ruby/gems/shared/gems/sassc-2.2.1/ext/libsass.so' : /home/enebo/Applications/jdks/zing-jdk11.0.0-19.12.101.0-2/lib/server/../../etc/libc++/libstdc++.so.6: version `GLIBCXX_3.4.26' not found (required by /home/enebo/work/jruby/lib/ruby/gems/shared/gems/sassc-2.2.1/ext/libsass.so)
<enebo[m]>
yay
<enebo[m]>
what in the actual hell is up with that
<enebo[m]>
ok experiment is done
<enebo[m]>
I believe I did not originally see this because bindex was complaining but I did not see that in the copious amount of output I happened to be generating with zing flags
<enebo[m]>
If I get this error it is that zing compiled their JVM with a different glibcxx than is on my machine and dynloading that is a bad scene
<enebo[m]>
that == sassc
<headius[m]>
you got the Java 11 one?
<enebo[m]>
yeah
<headius[m]>
ah
<headius[m]>
did you test anything but rails?
<headius[m]>
that looks like it's having trouble with its own glibc
<headius[m]>
oh no I see
<headius[m]>
sassc is compiling something that uses libstdc++ and so when it tries to load it fails because zing has its own preferred libstdc++
<enebo[m]>
no. I mean I could try something simpler but I am testing HEAD atm
<enebo[m]>
I will circle back and try -e 1 or something
<enebo[m]>
well I think it is that was compiled with a different version than I have and it expect .so loads to use same
<enebo[m]>
yeah
<headius[m]>
yeah
<headius[m]>
set your LD_LIBRARY_PATH to include zing's libstdc++
<headius[m]>
probably have to rebuild sassc
<headius[m]>
or just test something that doesn't use sassc :-)
<enebo[m]>
I can try -e1 perhaps first
<enebo[m]>
just to see if it hangs or not
<headius[m]>
so you never got past the hanging on exit?
<headius[m]>
I mentioned it to Philip Reames from Azul on twitter
<headius[m]>
he's the one who poke me about trying Zing
<enebo[m]>
ok was rerunning with current HEAD on non-zing
<headius[m]>
I should start a bytecode dump of new AOT
<enebo[m]>
I do not likely see any difference...it looks very much within the realm of noise of a difference
<headius[m]>
bytecode trace I mean
<enebo[m]>
I was thinking we should put line number on staticscope
<enebo[m]>
it would get rid of a bunch of ldcs
<enebo[m]>
which I am sure are not a massive amount of code but if this is all running bytecode interp then perhaps it adds up
<headius[m]>
yes
<headius[m]>
oh well versus ldc, it's probably more expensive
<headius[m]>
but it's more bytecode
<headius[m]>
it wouldn't be more bytecode than a load scope + call method though
<headius[m]>
ldc of a constant is just about as cheap as you can get except for the specialized iload_1 and such
<enebo[m]>
It is just that it keeps pushing it down the stack into compiled method too
<enebo[m]>
it probably never leaves the same register but still
<headius[m]>
ah right I did just encounter that, had to add ldc to get the file and line into something
<enebo[m]>
I guess CompiledIRMethod and AbstractIRMethod constructors do warm quickly to C1
<headius[m]>
yeah file and line LDC could be eliminated if they're carried by a StaticScope
<headius[m]>
+1
<headius[m]>
ok finally going to do my lunch routine while this thing chews on bytecode trace
<headius[m]>
we'll see if the new AOT files are cheaper than old
<headius[m]>
did you try CDS with new AOT?
<headius[m]>
if not that would be worth a quick check
<enebo[m]>
I did not but I will try
<headius[m]>
FYI I chatted with @cla4es from Oracle and he said CDS can't do much to help method handles, even constant ones like for lambdas, but jlink can
<headius[m]>
so jlink is definitely another "future" thing we need to try
<enebo[m]>
so CDS is 13.8s with --dev vs 14.[45] ish
<enebo[m]>
that is with the 1400 classes
<enebo[m]>
so --dev and classcast with all those classes is like 14.4s and with CDS of those it is 13.8 (also using --dev)
<enebo[m]>
With 143 class version from my behavior gist time drops from 12.1s to 11.[56]s
<enebo[m]>
so CDS is definitely helping but not massively so
<headius[m]>
so with cds we're starting to see a gain
<enebo[m]>
but considering a plain --dev is 14.4s or so and this is pretty good
<headius[m]>
ok so clarify
<enebo[m]>
interesting that with how things are we can probably sweet spot this a little bit by not running very much
<headius[m]>
--dev no class cache + cds is what
<enebo[m]>
14.4s
<headius[m]>
what's --dev no cache without cds?
<enebo[m]>
sorry I never ran your firsto ne
<headius[m]>
oh
<headius[m]>
--dev + cds is the fastest scenario i have seen for most commands
<headius[m]>
so I'm curious about that
<enebo[m]>
ok I will give it awhirl
<enebo[m]>
I am going to write a script to test all of these
<enebo[m]>
and kill my browser when I run it
<headius[m]>
probably sleep a bit between to try to reduce chance of throttling
<enebo[m]>
yeah not a bad idea
<headius[m]>
I'm going to try to figure out jlink since I'm sure that will come up
<headius[m]>
we are a better module citizen now so it may be possible
<enebo[m]>
yeah I think jlink has a second good possibility of eliminating some modules
<enebo[m]>
not really sure how much is actually loaded or not already but ??