<headius>
boo, can't use LambdaMetaFactory with a CallSite dynamicInvoker
<headius>
enebo: so I took a little side tour considering how to do always-on tracing
<headius>
with indy of course we can make most of the trace calls be no-op and not impact performance generally speaking
<headius>
we can't in the other modes, but I'm wondering if it matters... for performance you should be running indy anyway
<headius>
another option is moving the trace flag to be JVM global... you wouldn't be able to have one runtime call tracing and another runtime not call tracing but it shouldn't matter because you're already opting into slower perf if you use tracing
<enebo[m]>
I am unsure. this cannot be done through reasoning alone
<enebo[m]>
interp perf does matter in one case
<enebo[m]>
CI runs
<headius>
true, but the always-on case basically would just add one virtual call to runtime.callTrace and one boolean check in there to see if hooks are set
<enebo[m]>
I guess it is just something to measure
<enebo[m]>
It could be it doesn't impact that but I doubt we want 10% more time spent on peoples CIs?
<headius>
yeah I would need to try this out and measure, both straight-line perf and any cost from adding trace instructions in JIT all the time
<enebo[m]>
Another thought is some tracepoints perhaps should not be instrs if they can just be stuffed into interp or emitted via bytecode generation (for boundaries
<enebo[m]>
it also will have a bytecode cost sizewise
<headius>
c_call and c_return get generated into the DynamicMethod invoker classes
<headius>
I think raise and class are always on because they're heavyweight operations anyway
<enebo[m]>
but call and return could be java code in interp and not instrs
<enebo[m]>
JIT would have to do something but that could be indy
<headius>
actually I should say I'm interested in the call/return traces being always on... not going to try to do line always on
<enebo[m]>
IR has normative entry/exit BBs so for JIT it just puts those two there
<enebo[m]>
so interp having to check one field per entry/exit per method is probably not going to be noticed
<headius>
Right
<enebo[m]>
JVM with checkpoint will just increase overall bytecode size
<headius>
I think it's possible to make everything disappear with invoke dynamic but I can't eliminate the bytecode cost of those entry and exit instructions
<enebo[m]>
I think call/return can just be implicit in both modes
<headius>
So that impacts our budget a little bit for every Ruby method
<enebo[m]>
interp will gain something but it will be a magnitude faster being implicit rather than instrs
<headius>
So you're saying just do the call in the interpreter rather than as an instruction?
<enebo[m]>
yeah for those two
<headius>
And likewise in the jet output, always admit the entry and exit logic, possibly with Indy
<enebo[m]>
line we should still emit instrs
<headius>
Jit
<headius>
Yeah line is a huge overhead and largely unnecessary
<enebo[m]>
yeah seems like we could get away with that without massive perf changes
<headius>
I am surprised MRI has not added a flag to turn line events on
<enebo[m]>
if no tracepoints enabled it should never go into an if which does the emitting
<enebo[m]>
or at least that would be desirable
<enebo[m]>
so normal run with no diag gems hitting that stuff and even the interp would just be a couple of if checks on a field somewhere
<headius>
At minimum the jit would need to load contacts and make the indie call, so that times two for every method body
<headius>
Context not contacts
<enebo[m]>
yeah. I guess it is tough to speculate any further but interp without those instrs I predict will not change perf very much
<headius>
Four bytecodes, probably 10ish bytes
<enebo[m]>
JIT I don't know
<enebo[m]>
I would be more worried about overall bytecode size per method but only for tiny methods
<enebo[m]>
and I suppose methods which just squeak in at native size (although that is probably so rare already)
<headius>
Without Indy it's more like 6 bytecodes per entry and exit to load the values
<headius>
I'm not too worried about this having a measurable impact in the interpreter but it would be more noticeable in non-indy JIT code
<enebo[m]>
As non-instrs I doubt interp is an issue
<headius>
That would be easy to test right now. Just always admit the entry and exit and compare
<headius>
This is mostly to get closer to having all the trace events on by default fewer cases trigger those warnings
<enebo[m]>
yeah I like the idea of seeing at least
<enebo[m]>
one less mismatch for people trying us too
<headius>
I could even do line events with Indy but that's adding a lot more bytecode so not feasible
<enebo[m]>
until a deopt system is in place I think it doesn't make sense
<enebo[m]>
I guess the details how when that deopt occurs is interesting but at some point being able to raise and spil state (or even just recompile for next entry is a 90% solution)
<headius>
yeah what can you reasonably expect when you flip line events on
<enebo[m]>
ARGV does this when file changes and I think it is doing it but it does not seem to be seen on something accessing it (or it does but not quite)
<headius>
oh right
<headius>
ARGV
<enebo[m]>
globals are indified?
<enebo[m]>
Is it possible we are not seeing this get replaced?
<headius>
they've gone back and forth
<enebo[m]>
hmm this may just have the wrong logic
<enebo[m]>
well enough for today
<headius>
they are indified
<headius>
might not be getting invalidated properly
<headius>
I'm betting the $FILENAME global just sets a value directly and does not invalidate itself
<headius>
in non-indy mode it should be slow path always though and re-get it
<enebo[m]>
just passing it in twice is ok if one is on ** I guess
<enebo[m]>
Not sure if this is just some simple merge logic where this is ignored but this will be my first thing monday or possibly this weekend
<enebo[m]>
ttfn
<headius>
ok
<headius>
I will be working on and off all weekend
<enebo[m]>
coolio
<headius>
actually what am I saying... whether full trace is enabled or not is already global, so the local check is whether any hooks have been installed