<kares[m]>
1401 syscalls on Ruby, but tahn Python is close with 1200 😉
nirvdrum has joined #jruby
shellac has joined #jruby
rusk has joined #jruby
drbobbeaty has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
drbobbeaty has joined #jruby
shellac has quit [Quit: Computer has gone to sleep.]
rusk` has joined #jruby
rusk has quit [Ping timeout: 260 seconds]
shellac has joined #jruby
<enebo[m]>
I am sure Rust could get dialed way back compiled a little differently...although perhaps that is not the point
<enebo[m]>
I would expect python to do less since Ruby is at least read()'ing half the planet whereas python opts in on more stuff
lucasb has joined #jruby
ang-st has quit [Ping timeout: 265 seconds]
ang-st has joined #jruby
shellac has quit [Ping timeout: 248 seconds]
xardion has quit [Remote host closed the connection]
xardion has joined #jruby
nirvdrum has quit [Ping timeout: 240 seconds]
nirvdrum has joined #jruby
sagax has quit [Ping timeout: 258 seconds]
rusk` has quit [Remote host closed the connection]
rusk has joined #jruby
<headius[m]>
g'day! I'm back in the office
<headius[m]>
kares: I'm not sure how it performs on J9 actually, did not measure that. I assume some of this is in the class libraries they share with OpenJDK but most of the stack trace building happens in native
<headius[m]>
There's a lot of ugly bits in the stack walking though, like how half of the fields on those stack frames force the full StackTraceElement to be created
<headius[m]>
I think that's some of what they improved in 13
<lopex>
but hey, they have quite a few packages there
<headius[m]>
the libc changes are most liklely to cause problems but if openjdk runs we would work without native support
<headius[m]>
and really just need jnr bindings for termux to do the rest
<lopex>
you mean bionic ?
<headius[m]>
yeah
<headius[m]>
we still get reports of issues with e.g. musl but usually it's things in glibc that are nonstandard in the first place
<headius[m]>
like that whole __xstat64 nonsense
<headius[m]>
I'm going to triage bugs a bit today and tomorrow and then I've got to start working on stuff for fosdem and rubyfuxa
<headius[m]>
rubyfuzaa rather
<headius[m]>
huh, brixen must have terminated his rubysl project...the whole org is gone
ur5us has joined #jruby
<headius[m]>
enebo: I'm updating the reline+irb PR to latest... wondering what you think about moving away from jruby-readline in a minor release
<headius[m]>
reline is certainly more compatible than jline and now it's officially the readline for MRI
<headius[m]>
I need to confirm how they're doing that, and if they have a fallback for odd platforms.... and we may need to fall back on jruby-readline for a while on Windows since reline uses Fiddle there
<enebo[m]>
headius: fwiw I do not see jruby-realine to be a public API in any way so it is mostly a matter of reline being up for it. There seemingly has been some pretty basic errors still be reported but if those get addressed I do not feel too bad about the swap
<enebo[m]>
We have not really been happy with supporting this so reline is definitely the future :)
<headius[m]>
I think most of those errors have been resolved, but I just tried to update reline and it has a dependency on the io-console gem
<headius[m]>
we have support for io/console library but the gem is the MRI C ext
<enebo[m]>
heh
<headius[m]>
looks like io-console got pulled out to a gem in 2017
<headius[m]>
so speaking about priorities the next three weeks before FOSDEM
<headius[m]>
I am going to be Ruby AOT working so that it's possible to use that with GraalVM AOT
<headius[m]>
for fully-compiled native Ruby apps
<headius[m]>
that's my #1 priority since I really want to have it for FOSDEM presentation
<headius[m]>
#2 priority will be 9.2.10 since there's Java dispatch and some fiber leak bugs
<headius[m]>
#3 would be presentation/workshop for RubyFuza
<enebo[m]>
yeah I was thinking about #1 already as well but not because of graal
<headius[m]>
CDS and such too yeah
<headius[m]>
CDS and J9 quickstart/shareclasses
<enebo[m]>
I was thinking about the notion of figuring out what exactly we actually need from IRSCope and see how much can go to StaticScope
<headius[m]>
yeah I just need to be able to reconstitute the IRScope and StaticScope enough for the JIT code to run
<headius[m]>
which obviously wouldn't need the CFG, instructions, etc
<enebo[m]>
I am hoping to understand if we can decouple IRScope from runtime past recompilation/optimization
<headius[m]>
the main issue I ran into last time I started messing with this is getting the proper scope hierarchy installed in loaded AOT classes
<headius[m]>
a short term version would be to still do the full parse+compile but then say "do I have a native version of this already" and switch to it
<enebo[m]>
I was thinking a bit over the break that requiring all of that to exist to execute compiled code makes no sense and I am not really gung ho on a partial IRScope
<headius[m]>
oh so you're saying can be move more stuff to static scope and only depend on that
<enebo[m]>
well yeah and a little more possibly
<headius[m]>
yeah could be possible
<enebo[m]>
like if we have descriptor info we get from IRScope (just trying to remember what) we should consider encoding that into the compiled class directly
<headius[m]>
first stage for me would be auditing what jitted code needs from IRScope
<enebo[m]>
Or move it to static scope
<enebo[m]>
but consider what is runtime vs compile
<headius[m]>
it's not going to be much but some is shared IRRuntimeHelper code
<enebo[m]>
runtime static is static scope
<enebo[m]>
compile static is IR scope
<headius[m]>
yeah
<enebo[m]>
but there may be a third category here
<enebo[m]>
auditing is definitely a step
<enebo[m]>
I have to convert to my new laptop this week too
<headius[m]>
new thinkpad?
<enebo[m]>
yeah...got is xmas eve but only started moving stuff over last friday
<enebo[m]>
reauditing all files on current laptop to not move over a bunch of old crap
<headius[m]>
I hope 2019 MBP is approved soon because my arrow keys are only working about 50% of time