<daveg_lookout[m]>
Has anyone else reported issues with JRuby 9.3.4.0 and LOAD_PATH in warbler-generated executable JARs? If not, I'll try to put a simple example together. I have a gem that I turn into a jar, with binary that tries to find rest of gem via LOAD_PATH with require. It roughly looks like __FILE__ isn't working perhaps -- I can read files from the load path, but when I try to require them, it fails with "ERROR:
<daveg_lookout[m]>
org.jruby.embed.EvalFailedException: (ENOENT) No such file or directory - /lib/proxy/monitor.rb". Exact same code works with 9.2.9.0
<kares[m]>
would be great to have it on master asap so I could look into potential regressions ...
sagax has joined #jruby
<kares[m]>
pushed jruby-openssl 0.13.0 with some compatibility improvements and the requested (on twitter) to_java conversions
<headius>
daveg_lookout: That does not ring a bell so definitely file a bug
<headius>
kares: I have no objections to the cleanup
<enebo[m]>
kares: I am ok with it
<headius>
good morning
<headius>
today I'm putting together talk for RC so will be trying to some updated benchmarking
<headius>
enebo: the timeout gem thing did not seem to affect installing Rails 7, can you confirm?
<headius>
I think the JRuby impl could be released any time, but Benoit is also working on porting the Rubinius one over so we may not see a release right away
<headius>
the port he came up with seems broken... it gets progressively slower on JRuby and TR and has times all over the map on MRI
<enebo[m]>
I was able to fully run the simple crud app I normally test with once I made adjrbc 70.0
<enebo[m]>
nothing needs to be changed
<enebo[m]>
I did have to widen the spec in arjdbc yesterday so pull if you haven't recently
<headius>
I mean without defaulting the timeout gem and using the crap version, but I suppose that is sorta beside the point since we can install on current master anyway
<enebo[m]>
oh I can remove it I guess and see what happens
<headius>
if we don't have a better timeout release before RC I will just include that as a gotcha to watch out for if people start trying us soon
<enebo[m]>
so I figured out why we have no jruby-head but got frustrated debugging
<enebo[m]>
windows is not building in that job
<enebo[m]>
so it doesn't publish anything
<headius>
there should be a nightly snapshot that doesn't require any green suites
<enebo[m]>
It dies in fiddle trying to load a c-func which should be there
<headius>
the publish attached to normal GHA CI will not run because we are not fully green
<headius>
I do see nightly snapshots getting pushed to sonatype
<enebo[m]>
I mean jruby-dev-builder
<headius>
oh right
<headius>
so that one requires a windows build to work?
<enebo[m]>
I believe so
<enebo[m]>
It does make some sense you would want all supported platforms to be capable of building (even if that is a little weird for Java apps)
<enebo[m]>
So I know this should not be a huge effort to fix since 9.3 does run the thing it dies on
<enebo[m]>
but I first swipe was a fail :)
<enebo[m]>
I instead just fixed some more kwargs stuff
<enebo[m]>
actionmailbox is 1F now (which annoyingly is a kwargs + forwards issue)
<headius>
yeah I think we need to get that working before RC
<headius>
I can look at it this afternoon
<headius>
that = jruby-dev-builder jruby-head builds
<enebo[m]>
call(...) -> def a(b:) is thinking ... has a splat so it unmarks the rest arg
<headius>
one of the suggestions for people trying JRuby will be to add jruby-head so it should be current
<headius>
oh fun
<enebo[m]>
I guess the * in ... is not really a splat
<enebo[m]>
HAHA
<enebo[m]>
Also I should tell you that a callsite knowing about splat on the callside will be an early motivation to fix
<enebo[m]>
I only realized this morning that all invokers have to toggle that off
<headius>
Yeah I thought a bit about that and I think the worst case would be that we thread another callSplat path through methods and call sites
<headius>
In that way it is sort of similar to super calls which need to have a descriptor past for splat information
<headius>
s/past/passed/
<enebo[m]>
That took a long time to realize ...
<headius>
This is all big time motivation for me to figure out a way to run Indy all the time without a huge impact
<headius>
If we can get rid of our non-indee call sites then we only have one type of invocation through which we must thread keywords and splat info
<enebo[m]>
I guess the tiny handle chain for simple calls is the first step
<headius>
Maybe with a super simple in-line cash form of indy call site, or a shared call site that we bind an inline cache to so that it will optimize like the current call sites but leave us a path for optimization
<headius>
I have a meeting, be back in a bit
<enebo[m]>
So funny thing is the 1E which is the above mentioned forward+mandatory kwarg is only in a test method itseldf
<enebo[m]>
headius: I think I am confused...why did it take less time after rehearsal was done?
<headius>
yes
<headius>
like 50x faster
<headius>
I would expect the rehearsal to be slower but not 50x
<enebo[m]>
Is it actually benchmark-ips or benchmark?
<headius>
Benchmark.bmbm and I see nothing special that would make the rehearsal this much longer
<enebo[m]>
yeah I guess the other strange thing in this is why would the rehearsal not get progressifvely faster
<enebo[m]>
most of it is all the same update with different data types
<headius>
if the answer is somehow that it just runs rehearsal 50x before getting a single iteration for the result, so be it
<enebo[m]>
I can see how some stuff may decide to inline differently but a lot of that code will be the same path
<headius>
this benchmark should probably just get updated to use ips though, so I may go ahead and do that
<enebo[m]>
sure. I didn't write it and I am more used to seeing ips output
<enebo[m]>
but I think it really depends on how long the action in the closure takes
<headius>
right that is correct about rehearsal numbers all being largely the same...so I am assuming this runs a bunch of extra before the final run
<enebo[m]>
looks like this is all generated
<enebo[m]>
benchmark_create.rb
<headius>
I guess another thing about this is that it really shouldn't need to run each bench for a full minute to get some solid results... this must be millions of iters of each by that point
<enebo[m]>
HAHA. I don't even see why each update would be slow in rehearsal
<enebo[m]>
unless all our benchmark speed is it all reinlining to nothing because the data is never different
<headius>
probably unlikely
<enebo[m]>
I mean it is all calling through update which will be identical up until it hits native Ruby methods in the JDBC code
<enebo[m]>
I can see some fields just taking longer because not all db fields are the same but this seems pretty wild you would not see rehearsal just improve as it keeps executing update
<headius>
nice, indy is actually running these faster than non-indy
<headius>
I want some numbers but not if they are slower than MRI
<enebo[m]>
So the Ruby itself is a significant part of this
<enebo[m]>
I am trying to remember ... we did something way faster and some things about the same speed
<enebo[m]>
like insert or something was really unusually fast
<headius>
if rehearsal is any indication, indy results should end up a good 12-15% faster than non-indy, and reasonably faster than MRI
<enebo[m]>
You would have to look back to I think maybe last RubyKaigi or Mpls Railsconf slides
<headius>
sqlite3 is an oddity since we are going through a native library to do it
<enebo[m]>
those railsconf slides also used rubygems web app for benchmarking
<headius>
yeah I can include that slide
<headius>
this year is only a 30 min talk so I don't need much to fill the time
<headius>
and some of that will be JRuby status update info (like half maybe)
<headius>
oh yeah, these are good results
<headius>
indy was nearly 2x non-indy on update bench
<headius>
on java 17
<enebo[m]>
wow
<enebo[m]>
you using parallel?
<enebo[m]>
GC that is
<headius>
default, which should be G1
<enebo[m]>
I am curious to see how parallel compares since I always see it still win
<headius>
I'll do a run for fun
<headius>
but they have done a ton of work on throughput for G1
<enebo[m]>
G1 for short runs is still subpar
<enebo[m]>
AR unit tests run these 1s benchmarks to make sure some things vs some things with encryption are within a margin
<headius>
sorry I always think -pre like maven but for RG it is .pre
<headius>
any gem with .alpha as the last component is considered a prerelease gem
<enebo[m]>
ok thanks for confirmation. I am giving this a test locally and I will push out something
<enebo[m]>
The filename and exclude stuff is not import but who knows on Monday I can also probably .pre2 if it matters
<headius>
yeah cool, just so I have something I can say "install this if you want to play"
<enebo[m]>
yeah.
<headius>
these numbers alone are good enough for me to present so I am feeling good about the talk now
<headius>
this also may mean that indy has improved a lot since 8 and 11
<enebo[m]>
I should point out all work I have been doing has been against 7.0.2.4 of Rails but I see 7.0.3 is out now
<headius>
yeah I am running 7.0.3 for these
<enebo[m]>
I would not expect much of a change but just in case something weird starts happening
<enebo[m]>
After this I will fix 2 kwargs issues (**krest + super(), ... + kw:)
<enebo[m]>
I am bifurcating two calls for ** callsites one which omits an empty **kwrest
<enebo[m]>
Ultimately this can be solved by same callsite work but the IR solution is not horrible because it only affects IR at callsites which have **kwrest in them
<headius>
yeah whatever works for now... we clearly have some call path reworking to do to get these all optimized so I'm not concerned about it right now
<enebo[m]>
so I am still getting 50.0 with 70.0.pre. I am going to bundle update --pre and see if it replaces it
<headius>
yeah you need pre
<headius>
pre flag to bundler
<enebo[m]>
yeah but rails runs bundler itself
<enebo[m]>
I updated my script to manually run with update
<enebo[m]>
unless there is a mechanism for pre to rails
<enebo[m]>
I put it on the command-line and it did not complain but ??
<headius>
I'm not sure if there's a flag for pre gems when generating or not
<enebo[m]>
bleh --pre is not valid on bundle update either
<enebo[m]>
yeah ok so worst case someone has to edit their gemfile once generated to this
<enebo[m]>
I guess for me this afternoon I just want to make sure this is all cool
<enebo[m]>
Using activerecord-jdbcsqlite3-adapter 70.0.pre (java) (was 50.0)
<enebo[m]>
Rails people know how to do this stuff but the 50.0 thing is offputting
<headius>
Nice
<headius>
Of course this will pull in pre-versions of the other gems but at least this is a way
<headius>
Yeah that's why I've been poking you about some sort of release
<headius>
And I am still very confused why it uses 50 instead of 60
<enebo[m]>
HAHAHAH OMG
<enebo[m]>
Rails is magic
<enebo[m]>
because my runner script could not perform migration with 50.0 I forgot
<enebo[m]>
I started up the server and it told me my migration has not run
<enebo[m]>
WITH A BUTTON 'perform migration'
<enebo[m]>
hmm .pre is enough right? I have no desire for make more than one
<enebo[m]>
It will just bug people with OCD if we do and we put out .pre2
<headius>
It's alphabetical so if we do need another one .pre1 would become the latest version
<enebo[m]>
yeah so we are fine
<headius>
I think pre with a number is the de facto standard way
<headius>
But I don't care and it probably doesn't matter
<enebo[m]>
I think next release will be 70.0
<enebo[m]>
yeah I don't care and I should have been so lazy to not even mention it
<headius>
Yeah I don't think we're going to need to iterate much on these once we get them updated
<enebo[m]>
ok the .pre stuff is out
<enebo[m]>
headius: may be worth verifying all is well with that release as second confirmation
<headius>
Sure I will try generating a new app here
<enebo[m]>
fixing super() thing now
<enebo[m]>
I will try and put some time in tomorrow and sunday but it will only be a little bit
<enebo[m]>
I have been largely just hitting noticeable problems that Rails tests are uncovering
<enebo[m]>
which has been a really good suite since it does a lot of language feature combos at the same time
<headius>
Yeah I have a pool tournament tomorrow so as long as we keep winning I won't be working on this, but after that I will be working to get the presentation together until my talk on Tuesday
<headius>
At this point I should have plenty of content with j Ruby update, Rails 7 support status, and some benchmark numbers