<kares[m]>
to take this further, maybe each (custom) GlobalVariable should decide what to do with its invalidator (stuff such as ERROR_INFO setting up a no-op) ?
<kares[m]>
actually likely the logic also needs to be reviewed on the global variable caching end
KeyJoo has joined #jruby
<enebo[m]>
I did not totally follow this ... you changed that raise to explicitly set vs retrieving from a table but I don't follow what this has to do with invalidation
<kares[m]>
pre 9.2.7 every raise followed the GlobalVariables path where its not just a simple `set` but also `invalidate` (and `trace`)
<enebo[m]>
oh so in 9.2.8 it is just a set now?
<kares[m]>
yes for `ERROR_INFO` specifically
<enebo[m]>
ok so you are now looking at other globals and wondering about how to do these since not all need to do invalidate/trace or some generic logic
<kares[m]>
actually I was looking at a Rails app recording where invalidation pauses the app for seconds
<enebo[m]>
yikes
<kares[m]>
since I do not know what constant was invalidated (+ do not have good info in traces) ... just following some common stuff
<kares[m]>
ERROR_INFO comes as a good candidate causing issues as libraries might use `$!`
<kares[m]>
which pbly means on every raise triggering invalidation of those ...
<enebo[m]>
although typically if a raise occurs then our performance has some potentially serious issues
<kares[m]>
but I did not check the details yet - if this would happen in 9.2.7 (app is 9.1.17)
<enebo[m]>
I would almost suspect the construction of tracing would be more than any invalidation but???
<kares[m]>
yes that is true but not locking
<enebo[m]>
ah locking
<kares[m]>
seems with many threads from time-to-time things get ugly
<enebo[m]>
ok yeah makes sense since these are in a table
<kares[m]>
in general, does it make sense to actually cache thread-local globals?
<kares[m]>
this what I was thinking about - if there's repeated `$!` read
<enebo[m]>
well thread local storage must also have some lookup but I guess how much would depend on how useful keeping it cached locally matters
<enebo[m]>
obvously some variables get referred to a lot but special variables tend to be assigned relatively quickly
<enebo[m]>
$_ and $! seems like candidates of an assignment since how they are used may actually set a new $_ or $!
<enebo[m]>
or $~
<kares[m]>
true, still in case of multiple threads stepping on a site that caches a global such as `$!` I am not sure about the benefits
<kares[m]>
guess we'll need to micro benchmark but the lock is very unpredictable
<kares[m]>
still
<enebo[m]>
yeah in that case it seems counter productive
<enebo[m]>
in whatever you are viewing have you see what the exception is? I mean you maybe are looking at lowering this scenarios cost but I am curious if the exception is a mistake or somethign which happens reasonably
<kares[m]>
under an extreme case I am seeing the cost of invalidation going from 20ms -> 400ms (per thread)
<enebo[m]>
In general I am hoping with exception logging on we more or less do not see any exceptions with backtraces in a normal request
<enebo[m]>
wow that seems crazy high
<kares[m]>
nope unfortunately I only see traces of many invalidations happening all at once
<kares[m]>
under many threads -> effectively halting the app
<kares[m]>
yeah I was thinking about exception logging
<enebo[m]>
I have heard people talk about very long warmup tails on large JRuby apps but others are not bothered (and seemingly much shorter tails)
<enebo[m]>
Perhaps you found something specific which serializes something earlier on in an app which is dragging out those tails
<kares[m]>
maybe, its still early to tell at this point