<headius[m]>
enebo: where do we stand with jruby-launcher? We should get a .14 out soon and include a rebuild of the exe which I am not set up to do at the moment
<headius[m]>
if it works for you then we will need a sample env or further diagnostics
<enebo[m]>
headius: WFM
<enebo[m]>
err let me try java 11 though I was on 8
<enebo[m]>
still works
<headius[m]>
ok I will ask for more info... perhaps native support is not loading with --dev and that env
<enebo[m]>
yeah that could be
<enebo[m]>
-e:1: warning: executable? does not in this environment and will return a dummy value
<enebo[m]>
"does not"
<enebo[m]>
but it still works even with that poorly worded warning with native disabled
<enebo[m]>
headius: note too he is using a specific glibc on debian
<headius[m]>
it is a debian base but uses Nix for packaging and stuff
<headius[m]>
so the paths to standard libraries and things are weird
<headius[m]>
he previously had to work through it being unable to find the correct libc which is why he has to set that JAVA_TOOL_OPTIONS thing
<enebo[m]>
I wonder how I figure out which version this is: libc.so.6 => /lib64/libc.so.6 (0x00007f8b36cbb000)
<headius[m]>
apparently all linuxes call libc libc.so.6 now regardless of version, or some nonsense like that
<enebo[m]>
I used nm
<enebo[m]>
000000000016efb0 W advance@GLIBC_2.2.5
<headius[m]>
it does seem like a native binding thing
<enebo[m]>
I assume that is right and it is not some weird old symbol entry :)
<headius[m]>
it is curious that this is coming from waitpid because I recently heard from someone at RH openjdk team about JRuby producing EAGAIN for waitpid but it turned out to be something else
<headius[m]>
Andrew H was investigating a customer issue that apparently involved JRuby
<enebo[m]>
well I am only riffing off what we can see in the report but who knows. if jvm was compiled against different shared lib and is still somehow linking to it. not ABI but close enough to almost work
<headius[m]>
yeah we just need more info or a sample env
<headius[m]>
I am still curious who this customer was though 🤔 JRuby peeps all over without us knowing
<enebo[m]>
headius: I landed a fix on 9.2 for something a logstash user reported
<enebo[m]>
It is very localized so I did not see any risk
<headius[m]>
ok I will probably see that during triage this morning
<fzakaria1>
I put some reproduction information for you guys
<fzakaria1>
i pinned the versions and everything should be straightforward to reproduce if you don't mind installing Nix (can be done on any linux distro and is easy to uninstall)
<fzakaria1>
headius: @en
<fzakaria1>
@ene
<fzakaria1>
enebo: it happens without any modifications to lib paths as well.
<fzakaria1>
I `unset JAVA_TOOL_OPTIONS` from my bug description and it still occurs.
<headius[m]>
fzakaria: if you can provide a vagrant or docker or vbox that would speed up reproduction
<fzakaria1>
okay let me see.
<headius[m]>
maybe there is a canned nix vbox image that will repro?
<headius[m]>
jffi 1.3.1 and upstream going out now
<headius[m]>
jnr releases take so long and feel like wasted time
<headius[m]>
need to commission someone to set up a single maven project that can do it all at once
<headius[m]>
enebo: I pushed PRs for master (jffi is the only substantive update) but also for 9.2 which was behind on most of the JNR projects
<headius[m]>
there have been various bugfixes across jnr-* that probably should go out in 9.2.14
<headius[m]>
the PRs will fail because maven but I'll poke them later
<enebo[m]>
ok
<byteit101[m]>
headius: That issue is a bit weird in that "success" is slightly different error messages for the interface I chose to file with. Probably could have found a better interface
<headius[m]>
yeah I am not actually surprised that we might be handling default methods incorrectly, but I would have expected to see more bug reports about it
<headius[m]>
the anonymous interface impl `Bad.new` creates could just be another anomaly
<byteit101[m]>
Yea, I though it was a simple thing I could fix in my PR (see comments on the 28th here above), but then saw the .new issue and realized the scope
<byteit101[m]>
I think the thing that has prevent bug reports is that it works once you to_java it, either explicitly or via passing to java code
<byteit101[m]>
*aside from the super calls
<headius[m]>
so we do bind the methods correctly for classes entering Ruby from Java but not for interface impls created in Ruby
<headius[m]>
that is not as wide a scope then
<byteit101[m]>
(see latest update in issue)
<headius[m]>
ok
<headius[m]>
yeah so something we do when setting up a proxy for a previously unknown Java class is not happening when generating the proxy class for a new interface impl
<headius[m]>
may be an easy fix
<byteit101[m]>
The super thing will require some coordination as I've heavily modified that area in my PR, but the .new thing shouldn't
<byteit101[m]>
Oh! I also found a bottleneck in Array.set when `[x].to_java`. Is there a reason for non-primitives using Array.set in RubyToJavaInvoker.convertVarArgumentsOnly ? Changing to an actual array set gave me a 10x speedup