<headius>
Never occurred to me before... We should make dev mode just bump the jit call count way up. Still get benefits of interpreting at the beginning, but if it keeps running still get to compiled bytecode
<headius>
Might also be able to tweak JVM to stay in C1 longer but tiered makes slow code so maybe not
<enebo[m]>
headius: I would be curious if any amount of tuning would be helpful for longer CI runs where most code is new but it clearly hits some common code enough
<headius>
There's so many tunables for tiered
<headius>
I have not played with them at all
<headius>
Of course we still need to retool how we decide to hit in general too
<enebo[m]>
I think even just tuning jit threshold is interesting since our --dev still builds full
<headius>
Disabling our jit is not a huge part of dev mode gains
<enebo[m]>
so we are doing work and getting some benefit
<enebo[m]>
yeah I know tiered is most of it
<enebo[m]>
Timing C1 bytecode from JIT is an interesting exercise though
<enebo[m]>
It could be quite a bit faster and our main problem was just too much JITing of stuff not needed
<headius>
Right
<headius>
We got a lot of stuff we don't need to
<headius>
Jit
<enebo[m]>
My attempt at timing-based JITting using rate of change did not really pan out but I am still convinced it could work
<enebo[m]>
Now it has been long enough I don't remember why it didn't work
<enebo[m]>
I think calibration was an issue (e.g. not all machines will compile at same rate due to hardware) but beyond that there was another problem
<headius>
I still like backedge counting
<headius>
Or instruction count but that is costly
<headius>
There's so much we could gain leaping to JDK 17
<headius>
We should float that idea for X
<enebo[m]>
yeah I think it is a good idea
<headius>
Vector API for codepoints calc comes to mind
<headius>
Or byte searches
<headius>
Disclaimer: I know very little about the capabilities of vectorization
<byteit101[m]>
simdjson is an impressive-to-me use of vectorization for json parser
<headius>
Ah yeah
andrea[m] has left #jruby [#jruby]
<byteit101[m]>
wait, what's the difference between FD and [:child, FD]? "redirect to the file descriptor in parent process" vs "redirect to the redirected file descriptor" is what Process.spawn says. Does :child not participate in temporary swapping?
<headius>
Hmm
<headius>
I implemented this I should remember 🤔
<byteit101[m]>
btw, how's the conf going?
<headius>
Finished up today, lots of good talks and hallway track
<byteit101[m]>
nice!
<headius>
One of those may open a new fd and the other expects it to be open already?
<headius>
I'm not sure
<byteit101[m]>
nope, FD = int
<byteit101[m]>
the only thing I could think of is that parent participates in a graph-solving of fd shuffling (in: :out, out: :in) generates a temporary, whereas :child might?
<byteit101[m]>
been procrastinating the graph solving for a few days, hoping to do tonight
<headius>
The docs for this are terrible, I'd have to look at the spawn code
<byteit101[m]>
it's nasty :-)
<headius>
I ported that for JRuby
<headius>
It is still nasty
<byteit101[m]>
I was referring to the C in MRI
<byteit101[m]>
I just don't see the point of :child
<byteit101[m]>
I mean you could replace that with the ruby Impl I'm cooking up for posix. Implement subspawn-win32 and then could use on all platforms
<byteit101[m]>
which is actually why I'm trying to make it compatible with Process.spawn
<byteit101[m]>
which I think is an alternative way to say {[a, b] => c}, as {a => c, b => [child, a]}, right? or am I misreading this?
<headius>
Seems plausible 😀
<headius>
So redirect to an fd that was previously redirected
<headius>
Because otherwise it might get wiped out?
<byteit101[m]>
no this is the reverse though? redirect to one that was wiped out
<byteit101[m]>
ah, the finally first use case to make sense to me: In this case, IO.popen redirects stdout to a pipe in the child process and [:child, :out] refers the redirected stdout.
<headius>
Yeah so it is an fd from parent that was redirected, use that in the child
<headius>
Ahhh ok
<byteit101[m]>
a way to access specified-down-the-call-stack redirections that the user doesn't have access to
<byteit101[m]>
so at my level I can merge them, but users may not be able to
<byteit101[m]>
</confusion>
<headius>
I'm not sure where this set of features came from