xardion has quit [Remote host closed the connection]
xardion has joined #jruby
rusk has quit [Remote host closed the connection]
shellac has quit [Ping timeout: 264 seconds]
jrafanie has joined #jruby
subbu|breakfast is now known as subbu
<headius[m]>
kares: That seems fine to me for now
<headius[m]>
We need to get this stuff all landed for 9.2.9. enebo was considering making the new threshold stuff be opt-in for this release since we have only had a short time to test it
<kares[m]>
fine by me - there was an issue with parsing longs that might need a options lib update
<kares[m]>
all (enebo's jit.time.delta work) on a branch in a PR - feel free to take it over
<kares[m]>
one thing of a change that I did not handle - is that even when time.delta is disabled it still takes the initial nanoTime for every method ... should not matter but still if there's plenty of evals going on (new methods added)
<enebo[m]>
kares: If we can even measure that I guess we can still just add a conditional around it too
<headius[m]>
kares: I can give you access to options if you know what needs to be fixed
<enebo[m]>
recently I did a simple rails app and almost 19000 methods were registered
<enebo[m]>
so 19k nanotimes seems like nothing to me but what do I know
jrafanie has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<headius[m]>
kares: added you to headius/options
<headius[m]>
oh hey different topic
<headius[m]>
enebo: so you are on board with saying matrix is official channel now?
<enebo[m]>
headius: matrix or riot
<enebo[m]>
or is riot matrix
<enebo[m]>
I realized I keep saying those two names interchangeably
<headius[m]>
Riot is the matrix client
<headius[m]>
they can use whatever though...aren't you using something in pidgin?
<enebo[m]>
ah ok so my brain remembered that at some lower level
<enebo[m]>
it was flaky but I am hopeful it will eventually be better
<headius[m]>
I think we should still maintain Gitter for now because that integration has never worked 100%
<headius[m]>
and it was ugly as hell anyway
<enebo[m]>
I am betting open protocol ends up winning the race
<headius[m]>
kares: I assume you would have no objection to that
<headius[m]>
enebo: kares: another item I brought up the other night: non-pushed DynScope
<headius[m]>
right now when we flip the bit to say "this scope needs a dynscope" we always push it onto context
<headius[m]>
but in the case of say a block that just uses captured variables, there's no need to push the scope anywhere...we already construct the binding directly and bring it along with the block
<headius[m]>
the only cases that need to have the scope pushed to context are core methods that actively dig out local vars or construct new bindings (think #binding, #eval, #local_variables) but we could easily make another call path that passes scope through
<headius[m]>
if we could get scopes to not be pushed for simple blocks then we'd be a big step closer to escape analysis being able to eliminate them
<enebo[m]>
headius: I have always thought passing through one scope down (although the context is not just dynscope) would allow us to not have to alloc for those special builtin methods
<headius[m]>
yeah #local_variables doesn't actually need the dynscope I don't think
<enebo[m]>
john rose has always claimed there is no perf cost for that although I do believe it has a significant one of bytecode size
<enebo[m]>
and scala pushes like 30+ values to some calls or something massive...hard to believe that is not a cost
<headius[m]>
no cost once it jits
jrafanie has joined #jruby
<headius[m]>
but it affects jit parameters for sure
<headius[m]>
well no cost once it jits assuming register allocation works well
jrafanie has quit [Client Quit]
<enebo[m]>
yeah at some level I think it has to affect all the internal levers
<enebo[m]>
you set up a call with 30 params and you kill inlining
<headius[m]>
we're just totally defeating EA and other optimizations by pushing scopes onto this long-lived object
<enebo[m]>
well maybe anyways :) I presume most methods will do more than a single call
<enebo[m]>
yeah definitely true
<enebo[m]>
and maybe even defeating better EA impls like graal
<headius[m]>
can't even be constified because it's in an ARRAY in a field on a global object
<headius[m]>
so there's a bunch of mess there
<enebo[m]>
not that I would trade hotspot perf for better graal perf
<enebo[m]>
at least not today
<headius[m]>
right, I'd love to see graal actuall beat C2 on something but not at the cost of C2
<enebo[m]>
yeah C2 will be the major player for years to come even if graal replaced it for next JVM release
<enebo[m]>
with that said I should not have even went on that tangent
<enebo[m]>
the endless long lived dynscope may not help C2 at this point either
<headius[m]>
at the very least it's forced to boundscheck every access
<headius[m]>
we do blunt that a bit by loading once at method entry
<enebo[m]>
If we could prove it does EA and eliminates boxing scope data then it definitely is less work but does it
<headius[m]>
worth trying
<enebo[m]>
yeah definitely
<headius[m]>
related question...I see that local_variables does not actually use dynscope contents
<headius[m]>
but it does walk up dynscopes to get the static scopes
<enebo[m]>
we also probably need to bump to 11 as our default recommendation by end of year
<headius[m]>
is there any reason why we need to do that?
<headius[m]>
we can still push StaticScope if necessary becuse those are already long-lived
<enebo[m]>
especially if metaspace is much better than 8
<headius[m]>
so context.getStaticScope does not have imply there's a dynscope
<enebo[m]>
well they are just an artifact of parsing with a couple of live fields
<enebo[m]>
I would guess in most cases we just use field to walk them
<enebo[m]>
cref is only big live consumer isn't it?
<headius[m]>
primarily yeah I think so
<headius[m]>
my question though is why walk up DynScope instead of walking up StaticScope
<enebo[m]>
static is always there for one but we have the relationship that way because one is made before the other (and is always made)
<enebo[m]>
oh heh you asked opposite of what I said
<headius[m]>
yeah you can see RubyKernel.local_variables
<headius[m]>
it has a while loop walking DynScope until == null
<headius[m]>
but it only uses contents of static scope
<enebo[m]>
yeah I guess not always having a dynscope could be a reason but for thinkgs which want variables static makes more sense
<headius[m]>
I mean really this should be staticScope.getLiveVariables"
<enebo[m]>
so bi-directional link
<headius[m]>
getAllNamesInScope?
<headius[m]>
we have that already
<enebo[m]>
getNames()
<enebo[m]>
it is a scope and I am assuming people would assume all from the name already?
<headius[m]>
yeah it's supposed to be all names in scope
<headius[m]>
we may have some behavior difference regarding assigned vars but I'm not interested in addressing that if so
<headius[m]>
it does not check if they've been assigned in this code
<headius[m]>
there's no StaticScope.getNames
<headius[m]>
but there is getAllNamesInScope
<enebo[m]>
Interesting, I am betting the AllNames was a signifier that the invisible values would also be returned
<enebo[m]>
If I had picked that then I think getNames() and getLocalVariableNames() or something would be better
<headius[m]>
TIL -XX:-ReduceBulkZeroing
<enebo[m]>
lol
<enebo[m]>
the infinite stream of options in the JVM
<headius[m]>
no doubt
<enebo[m]>
Java conferences could have a fun competition having people name them or say what they do
<headius[m]>
give five options where only some of them are real and see who knows
<enebo[m]>
like that class name generator site
<headius[m]>
-XX:+AgressiveArrayAccess
<headius[m]>
-XX:+FastObjectInitialization
<enebo[m]>
HAHAH
<enebo[m]>
I honestly could not say that is real or not :)
<headius[m]>
yeah
<headius[m]>
they're not
<headius[m]>
I think?!
<enebo[m]>
-XX:+StringFactoryFactoryInhibit
<headius[m]>
-XX:+ReduceTimeDistortion
<enebo[m]>
tbh all the EE naming makes the class name stuff more plausible
<headius[m]>
because, you know, you can't eliminate ALL time distortion
<enebo[m]>
but -XX: is pretty all over the place namewise
<enebo[m]>
Some day someone will do a search for an -XX option and this log will come back and someone will try and use one of these options....THINK ABOUT THAT
<headius[m]>
I mean it does use dynscope stack inside ThreadContext to get the static scope, but it doesn't need the dynscope at all now
<enebo[m]>
how do you handle duplicated variables?
subbu|lunch is now known as subbu
<enebo[m]>
headius: there was a set so shadowed variables do not enter that list twice
<enebo[m]>
which if nothing breaks may be underspecified (or possibly we do the wrong thing)
<enebo[m]>
hmm restarted pidgin plugin but it maybe is not pinging when I do headius
<headius[m]>
well I did wonder if that would break
<enebo[m]>
Did you see my ping 2 above?
<headius[m]>
but no tests failed
<enebo[m]>
yeah I would say some nested eval with shadowed variables would be the test to try
<headius[m]>
I saw both pings
<headius[m]>
so tab ping may not be needed to ping
<enebo[m]>
ok so the highlight here in web client is just nicer and rendering names
<headius[m]>
yeah
<headius[m]>
seems like it
<headius[m]>
enebo
<enebo[m]>
yeah I just see red without the rendering around it
<headius[m]>
right so that's all good then
<headius[m]>
I'm 100% for official matrix
<headius[m]>
enebo: ok it does need to dedup
<headius[m]>
I'll fix that
<headius[m]>
you don't have any problem with this being StaticScope logic right? Seems like that's where it should live anyway
<enebo[m]>
no it should live there
<headius[m]>
👍
<headius[m]>
will add specs also
<enebo[m]>
coolio
<headius[m]>
I'm going to update community page to point at Matrix and do a tweet
jrafanie has joined #jruby
<rtyler>
headius[m]: hey you mind me asking you/enebo a recruiting type question? I don't want this to be thought of as solicitation in this channel in particular
<headius[m]>
sure, feel free to use DM if you don't think it's germane
<rtyler>
there may be some others who would be able to chime in
<headius[m]>
I have been getting a lot of pings from folks looking for help tuning JRuby apps lately...so that might be another worthwhile discussion
<headius[m]>
it doesn't seem appropriate for me to do that on OSS time
<rtyler>
I'm trying to find some folks somewhere between your understanding of JRuby and say kares[m], but in the MRI world. It seems like everybody in the MRI world works at GitHub :/
<rtyler>
we're not investing heavily in JRuby here, for better or worse
<headius[m]>
well we've been making an active PR push on JRuby lately so I'm hoping we'll find the folks that are already out there
<headius[m]>
but I don't know if I have a good list of who those folks are
<rtyler>
I noticed recently that Chris is at Shopify, which is another company in the same Ruby world as we are I believe :P
<rtyler>
large scale rails :P
<headius[m]>
lots of them are at logly
<headius[m]>
or whatever they're called now
<headius[m]>
yeah unclear what he'll be doing there
<enebo[m]>
rtyler: just so I understand you want MRI low level experts
<rtyler>
it's research, it's supposed to be unclear ;)
<headius[m]>
making this room truly official might help round people up
<headius[m]>
oh yeah you are looking for MRI people
<headius[m]>
yeah that's maybe even tougher
<headius[m]>
it's a difficult leap from Rubyist to C hacker
<enebo[m]>
rtyler: yeah much tougher if you ask me
<rtyler>
enebo[m]: I wouldn't say low-level experts, we're not tuning the VM the way Hongli Lai might be
<headius[m]>
even writing a C ext requires a deep knowledge of C
<headius[m]>
anyone who took Java at uni can muddle through a JRuby ext
<rtyler>
I think a lot about some of the cool work kares[m] has done around Active Record for JRuby, and that's about the right shape of person, but they're very difficult to describe
<enebo[m]>
rtyler: you looking to hire?
<rtyler>
indeed
<enebo[m]>
you said recruitment but I took that very abstractly :)
<enebo[m]>
ok
<rtyler>
at a previous employer we only had budget for contractors and it was a lot of fun working with mkristian for example
<enebo[m]>
scour the commit logs and then look up their linked in status for AR and MRI itself
<rtyler>
our ruby deployment here is large enough to were a staffed team would be in our best interest
<rtyler>
heh
<enebo[m]>
rtyler: I am not entirely joking but you may even just consider hiring someone with C expertise which is not a rubyist
<headius[m]>
enebo: dedup fixed on master with a spec, and I also modified Binding#local_variables to use the same logic (it had a duplicate of the scope-walking crap)
<enebo[m]>
someone with experience optimizing C applications. A fresh perspective may be a good way of making a breakthrough
<headius[m]>
enebo: that's not a bad idea
<rtyler>
enebo[m]: that's not an entirely crazy idea either :)
<headius[m]>
C hacker with some interest in Ruby
<enebo[m]>
I feel like most of us live in a very special bubble
<rtyler>
for funsies I'm floating the idea of running our main app on JRuby, I'm always curious to evaluate the price-per-compute hour of MRI versus JRuby
<headius[m]>
it occurs to me now that you should just see who wants a job from ruby-core
<headius[m]>
there's likely many core committers that aren't paid to do it
<headius[m]>
and they're already active
<enebo[m]>
rtyler: we will end up using a lot less startup CPU in next few months
<rtyler>
I don't frequent ruby-core, most of the mailing lists I'm on wouldn't welcome such solicitation
<enebo[m]>
rtyler: we are improving our JIT heuristics so we will likely be JITting less
<rtyler>
enebo[m]: startup CPU isn't a huge concern here, the disk I/O from loading the entire app and gem tree is already horrific :)
<rtyler>
we're migrating from a physical data center to AWS however, so the startup CPU might impact us more once we introduce auto-scale groups
<rtyler>
right now it really comes down to "how many unicorns can we cram onto a single box without having too disasterous of resource contention"
<rtyler>
of course, the JVM would change that dynamic, but then we might be threading in Puma rather than fork()'ing a bunch of rails
<headius[m]>
if you're getting more than a few unicorns we can probably hook you up
<enebo[m]>
rtyler: but if you xlarge with 40-60 threads on one runtime you are not running rails 15-20 times with 4 threads
<headius[m]>
that tipping point number gets smaller every week
<enebo[m]>
rtyler: I figure most of our extra CPU is just warmup and compilation
<enebo[m]>
since MRI doesn't do that at all
* rtyler
nods
<headius[m]>
tweak JRuby and run the whole app in under 1GB with dozens of concurrent
<headius[m]>
</salesPitch>
<enebo[m]>
but our warmup should consume less CPU in the near future and much less memory
<headius[m]>
you know this already though
<rtyler>
indeed
<rtyler>
the "no more C extensions" is a big selling point, but also a big stumbling point unfortunately
<enebo[m]>
yeah the sales pitch is not needed for you but the changes will make the calculus a bit more appealing (which is new info for you)
* rtyler
nods
<rtyler>
with Chris heading to Shopify, where does that leave the truffle work?
<headius[m]>
🤷♂️
<headius[m]>
all I know is they do a lot of work behind closed doors at Oracle
<rtyler>
that fits what I would have expected :)
jrafanie has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<headius[m]>
enebo: I feel like I should still at least mention the freenode channel even though most of interact with it via matrix now
<enebo[m]>
headius: sure I have a soft spot for freenode