<enebo[m]>
but if it works it is needed for whitespace
<enebo[m]>
as you know obviously based no that PR :)
<headius[m]>
oh it should have been outside quotes I wasn't paying attention
<headius[m]>
both work but I intended to restore original quoting, will fix that
<enebo[m]>
sh syntax is a use case in unfriendliness to me and always will be
<enebo[m]>
headius: but with the change I would just land that. .18 will get it
<headius[m]>
yeah I will land once it passes
<headius[m]>
I wanted a bug or PR so anyone searching for this issue would find it
<enebo[m]>
yeah
<headius[m]>
enebo: I just merged it, something is odd with 9.2 PRs and CI runs, it wasn't triggering travis
<headius[m]>
so evaluating risk on this... JDKs are rarely installed in paths with spaces on unixy systems, in fact I can't think of any Linux dist that would do it by default
<headius[m]>
on the one platform where it is common, Windows, we don't use the bash script
<headius[m]>
so the exposure here seems particularly low
<enebo[m]>
yeah I also came to the same conclusion
<enebo[m]>
people can downgrade to .16 or move their install location as a workaround too
<headius[m]>
that guy with the JAVA_HOME problems also filed issues about it
<headius[m]>
strangely he seemed to file two that are the same problem
<headius[m]>
this will need to be ported over to the C launcher as well, unless your launcher is ready to go
<enebo[m]>
yeah it is not ready to go but I did make some progress this weekend
<headius[m]>
I will have mrnoname review
<headius[m]>
he actually warned me about the removed quotes but I never got back to it to fix it
<enebo[m]>
String -> OsString is almost done but I still have some weird quote processing code to port and then verify the unix impls of the methods I wrote are working
<headius[m]>
so that one is on me
<enebo[m]>
It strikes me as a weird outcome in sh programming that due to space being allowed in the filesystem everyone has to add this extra ceremony everwhere
<enebo[m]>
but the legacy of sh lives on
<headius[m]>
I am surprised that person was on a unix and had Java installed in a path with spaces
<headius[m]>
it is Darwin but not installing the JDK in a standard place... unless that is a standard place now?
<headius[m]>
I need more info
<headius[m]>
he replied again and said that is where Oracle JDK 8 installed, so this might be a new problem we will see on MacOS
<headius[m]>
I have asked him to share his system info on the PR so others can find it and we can evaluate if more is needed here
<headius[m]>
we probably should have a jruby-bash-launcher gem that can overwrite the jruby script with fixes
ur5us has quit [Ping timeout: 245 seconds]
<headius[m]>
enebo: if anyone else reports this I will look into such a gem
<headius[m]>
native launcher should work fine as well for the space path thing
<headius[m]>
enebo: guy reported back... the path with spaces is where Oracle JRE installs
<Freaky>
This java symlink thing looks like it won't help on FreeBSD
<Freaky>
java is a symlink to a script that picks the appropriate version to launch based on environment
<enebo[m]>
I am starting to wonder if we should consider going java -XshowSettings:properties -version route
<enebo[m]>
This Take 0.05s on my machine
<Freaky>
0.135235.7 ms … 251.4 mss
<enebo[m]>
Freaky: the first call right?
<Freaky>
235.7 ms … 251.4 ms 11 runs
<enebo[m]>
interesting. My machine may be a bit quicker perhaps
<Freaky>
161.8 ms … 181.1 ms 16 runs
<Freaky>
16's faster than 1.8
<Freaky>
this is a decade old machine, so that seems likely
<enebo[m]>
I think first read for me is that slow but second read is what I reported. I feel like Java getting run twice will only pay that cache cost once
<enebo[m]>
Freaky how fast is jruby -e 1 for you
<Freaky>
2.831 s … 3.091 s 10 runs
<enebo[m]>
how about --dev since this is fun :)
<Freaky>
2.312 s … 2.438 s 10 runs
<enebo[m]>
-e1 is 1s for me and --dev -e 1 is 0.7s or so
<enebo[m]>
and that java command is about 0.05s
<Freaky>
this is a 2.1GHz dual hex core Westmere
<enebo[m]>
So at least on this machine which is only like a year or so old (maybe a little more) the cost of that is pretty low as a percentage
<Freaky>
sluggish cores but at least I have a reasonable number of them
<enebo[m]>
so .13-0.23s for that check is not totally unreasonable and we are not measuring how much time that part of the script takes (although I am sure it will be faster)
<enebo[m]>
If we added ~1% to startup time but never had another bug on version I think it would be worth it
<enebo[m]>
There is a big problem though with this strategy. Non-openjdk VMs may not have it
<enebo[m]>
well azul and graalvm have it
<enebo[m]>
I don't have j9 installed but I am betting they support it
<headius[m]>
there is a special -XinternalVersion but I don't think it provides java path
<enebo[m]>
how fast is this on your machine?
<enebo[m]>
time java -XshowSettings:properties -version
<headius[m]>
from 0.082-0.1 with 8 assuming I am running this right
<enebo[m]>
I realize I was in emacs shell which adds a small amount for output compared to terminal
<enebo[m]>
lol and I am grepping wrong thing possibly
<headius[m]>
lowercase v
<headius[m]>
but this is still just getting the version and does not tell us java home
<enebo[m]>
yeah 0.01s for me
<enebo[m]>
On windows we do not even look since we determine largely from registry
<enebo[m]>
Or I think so
<enebo[m]>
but version tells us modules or not
<headius[m]>
which is the main reason we try to get java home now
<headius[m]>
if we can run without java home and just use internalversion it might be good but I don't know that we can run without java home set at some point
<headius[m]>
mrnoname is looking over the script changes
<enebo[m]>
our fix will still not make your code work but it will not explode with an internal error
<enebo[m]>
This is a case of Ruby specifying something which does not work predictably across threads
<surge_g[m]>
i came across this very issue with split in multithreaded environment on Google, but I can't find that anymore for some reason. It's possible this has been reported?
<fidothe>
I popped at the beginning of the month with an issue that looked like a resurrection of https://github.com/jruby/jruby/issues/6160. I have created the simplest example I can that has all the characteristics but can't get it to repro locally. I was seeing the problem in production on 1 of 20+ AWS instances spun up to handle a job, so I'm not entirely surprised.
<fidothe>
If anyone has an idea how to create a better case, short of spinning up 100 AWS instances to see if any crash out, I'd love to hear it
<headius[m]>
surge_g: That is the underlying (unfixable) issue but we should do a better job of ensuring we actually have a MatchData before casting it (your bug)
<headius[m]>
it is the "same" bug but your case is worse because it errors
<fidothe>
surge_g: oh yeah, I had that one recently. I sympathise
<headius[m]>
fidothe: so this may be fixed on master (9.3) but I am not certain... kares was still struggling with this race there but I thought he managed to deal with it properly
<headius[m]>
he may have some test cases to exercise it better since he was working on it
<fidothe>
How stable is master right now? I could pretty easily rebuild my AMI to use it and take out my workaround to see if I still get the problem. Probably easy than cooking up an actual reproduction case 🤣/😭
<headius[m]>
it should be very stable
<headius[m]>
and if it is not we want to know it because it needs to be released soon!
<fidothe>
I will give that a try
<headius[m]>
enebo: I am tasking mrnoname with some incremental improvements to the script
<headius[m]>
no functionality changes you would need to track but improvements to speed it up
<headius[m]>
he suggested a small change to my symlink patch that looks a good 5ms faster by avoiding a fork
<headius[m]>
the slow bash on MacOS is a real bummer
ur5us has joined #jruby
<enebo[m]>
cool
<headius[m]>
symlink PR looks green and has mrnoname stamp of approval, I will merge
<enebo[m]>
ok
<headius[m]>
$ jruby --environment
<headius[m]>
jruby: unknown option --environment
<headius[m]>
native launcher never got environment flag
<headius[m]>
enebo: I want your new launcher!
<enebo[m]>
yeah I have been working on it last couple of weekends
<enebo[m]>
String -> OsString was much more complicated than I thought
<enebo[m]>
Although that is almost done
<enebo[m]>
Then unix testing since I wrote methods which I have not tried yet
<enebo[m]>
One more task for quote processing on windows that is needed
<enebo[m]>
and the last couple of things we landed in last month
<enebo[m]>
but CI runs for linux/macos/windows
<headius[m]>
cool
<enebo[m]>
and will generate binaries
<headius[m]>
native launcher essentially eliminates the entire cost of the launcher, unsurprisingly
<enebo[m]>
although I will probably locally build linux using xargo
<headius[m]>
so anywhere from 25ms=45ms on my local testing goes away with the native launcher
<headius[m]>
25-45
<headius[m]>
if I were still on the system bash it would be closer to 100ms
<headius[m]>
FWIW this test shows our --version is significantly slower than it used to be and this is 400ms before we even start booting JRuby instance
<headius[m]>
I am on Java 11 so we have the loss of bootclasspath and verify:none in play here
<headius[m]>
I pushed an additional test for JAVA_HOME with spaces by symlinking it into a spacey location
<headius[m]>
Freaky: if you think we could do something better to resolve java home on FreeBSD please open another issue (or PR a fix)
<headius[m]>
I am pivoting back to other things now that these two issues are resolved and tested
<headius[m]>
actually I guess I have to fix the native launcher
<headius[m]>
rather than getting 9.3 out
<headius[m]>
🙄
<headius[m]>
enebo: what maven version do you have? Mine is still using http for those DTD references
<enebo[m]>
amusingly last two versions of fedora core has fucked something up with maven so I am just getting my own copy
<enebo[m]>
I cannot fully blame them for the last ByteBuffer API mismatch but they seem confused why people would run older versions of Java
<headius[m]>
if they built with release 8 the ByteBuffer thing is not a problem
<headius[m]>
it knows how to use the 8 signatures instead
<enebo[m]>
but they didn't and seem to be unwilling to do that
<enebo[m]>
so the bug has been open like a year
<headius[m]>
chrisseaton: hey you seem to have cracked some nut on class vars I never managed... what do you mean when you say they are looked up lexically?
<headius[m]>
we have never bothered to cache or optimize them at all because they suck but if TR is able to optimize them to a load then we should be able to do the same
<enebo[m]>
I thought modules somehow made reads depend on who defined the cvar first
<headius[m]>
yeah I thought similar but could never quite sort out the rules to make the values cacheable
<headius[m]>
it is possible this behavior changed since Ruby 1.6 too... we have not significantly changed cvar code in a long time
<headius[m]>
if it is indeed lexical and static we could eliminate a lot of overhead and possibly memory usage by the CHM
<enebo[m]>
I added another line here which prints out b.g twice
<enebo[m]>
you will notice it accesses a different @@a in both cases
<enebo[m]>
I decided it made no sense to do this on twitter but I am not sure what static means in this instance
<enebo[m]>
chrisseaton: ignore me again. second b.g is still looking in A :)
<enebo[m]>
I convinced myself it was looking in B in one case and A in another
<enebo[m]>
I realize now it is I called class_variables() and not class_variables(false) so it was showing @@a in both but one of those was just showing it because it was displaying A's as well