AndyMaleh[m] has quit [Quit: You have been kicked for being idle]
siasmj has quit [Ping timeout: 268 seconds]
fidothe has quit [Ping timeout: 250 seconds]
fidothe has joined #jruby
siasmj has joined #jruby
sagax has quit [Excess Flood]
sagax has joined #jruby
<MateuszFryc[m]>
headius: any idea whether my mail with hs_err file from 16. Nov reached hot-spot-compiler group ? I still have no feedback from hot-spot group as well as I can't see in JBS my submission. You said you are the member of the group which is able to submit bugs directly. I am just wondering if I just need to wait or my submission vaporized somwhere ;)
<edipofederle[m]>
<enebo[m]> "edipo.federle: I have not seen..." <- well, me neither, but no idea what is the reason.
<headius>
Good morning!
<headius>
Mateusz Fryc: I will check for your email today and if there's no responses or it didn't post I'll file a bug
<MateuszFryc[m]>
that would be lovely if someone competent could push it forward ;)
<MateuszFryc[m]>
I have came across at this issue today twice, I added some logging to show how compiling events look like
<headius>
There's a JVM flag that will let you disable compilation for a specific method, I think, if a workaround would be helpful right now
<MateuszFryc[m]>
Yes, I know eventually I will use that, but I want to observe it a little bit more now
<headius>
Ok cool
<MateuszFryc[m]>
it looks as if there are OSR compilation on other than 408 byte, then it works well, when compiling occurs at 408th byte it crashes.
<MateuszFryc[m]>
Server is being restarted as I use god gem as a watchdog, though currently running tasks are interrupted abruptly...
<MateuszFryc[m]>
not sure what more I could do to help solve this puzzle ;]
<MateuszFryc[m]>
Would it be possible to increase probability of OSR compilation at 408 byte of this method ?
<MateuszFryc[m]>
So I would have to reverse engineer somehow bytecode to java source, and create jruby source code with magic particular magic comments, probably?
<MateuszFryc[m]>
As I still didn't manage to create simple reproducible snippet.
<MateuszFryc[m]>
here is a bytecode generated from method at compilation of which jvm crashes
<MateuszFryc[m]>
I dont have experienec with converting bytecode back to sourcecode, so I am not sure where exactly this method we could be at (being at 408 byteceode), probably some mehtods are also inlined.
<MateuszFryc[m]>
s/I dont have experienec with converting bytecode back to sourcecode, so I am not sure where exactly this method we could be at (being at 408 byteceode), probably some mehtods are also inlined./I dont have experience with converting bytecode back to java sourcecode, so I am not sure where exactly this method we could be at (being at 408 byte of bytecode), probably some mehtods are also inlined./
<MateuszFryc[m]>
Not even sure if this is a right direction ..
<MateuszFryc[m]>
or better to live rest to jvm engineers ;)
<MateuszFryc[m]>
s/live/leave/
<enebo[m]>
public boolean parser_magic_comment(org.jruby.util.ByteList magicLine);
<enebo[m]>
This method I think is years old so it makes me think this is some regression on the JVM itself.
<enebo[m]>
Not sure if it is an option to try and use an older release of Java but that could be a workaround (it would take effort as well to pick the right version since we don't know why this is happening)
<MateuszFryc[m]>
hmm, this is byte code which my IDE (Eclipse) generated for 9.3.1.0 jar
<MateuszFryc[m]>
s/generated/showed/
<enebo[m]>
If your snippet is the method which is dying then it is very common code for processing top-lines of Ruby source files for things like '# encoding: utf-8'
<enebo[m]>
I also assume this tends to happen pretty quickly?
<enebo[m]>
I would expect the JVM to optimize parsing-related code prety shortly after startup
<MateuszFryc[m]>
well, I haven't noticed any particular happen apart from the one that it always fails at compilation of this particular method with OSR_BCI = 408. IT happens ocassibially.
<MateuszFryc[m]>
s/ocassibially/ocassionally/
<MateuszFryc[m]>
s/well, I haven't noticed any particular happen apart from the one that it always fails at compilation of this particular method with OSR_BCI = 408. IT happens ocassibially./well, I haven't noticed any particular happen apart from the one that it always fails at compilation of this particular method with OSR_BCI = 408. IT happens ocassionally. i.e 7 times so far (during last week)/
<enebo[m]>
but when your process is first starting or will it just happen later? (the parser runs for evals so it is possible this does not happen immediately)
<MateuszFryc[m]>
either at the very begnning of working or after several days of working ;)
<enebo[m]>
interesting.
<enebo[m]>
Not actionable per se but I hoped at some level the JVM would be done with the parser-related code quickly since it mostly occurs at startup time.
<MateuszFryc[m]>
so these are tmes when jvm crashed and generated hs_err with this exact error
<MateuszFryc[m]>
sometimes it works 2 days, sometimes it runs 20 minutes and crashes
<MateuszFryc[m]>
I had a hope that if it doesn't crash then I am good till I restart it manually, but id occurred I was wrong, probably because of deoptimization process..?
<edipofederle[m]>
enebo: maybe you can take a look at the https://github.com/jruby/jruby/pull/6927 ? all tests regarding slice with ArithmeticSequence now pass, but not sure how fix another CI issues
<MateuszFryc[m]>
s/id/it/
<edipofederle[m]>
I will squash the commits, btw
<enebo[m]>
Mateusz Fryc: yeah that could be. That method is really large by Java standards as well so any speculative opts probably will cause some deoptimization
<enebo[m]>
edipo.federle: I will check but it feels like there is some existing method for doing what aryMakePartial does
<edipofederle[m]>
enebo[m]: I can check it,
<enebo[m]>
edipo.federle: look at RubyArray.subseq
<enebo[m]>
edipo.federle: otherwise it looks like you did a faithful port of rb_ary_subseq_step
<edipofederle[m]>
yeap :D it ideally need some refactoring, I guess :)
<enebo[m]>
So just change for subseq and I guess squash and I will merge it
<edipofederle[m]>
cool, I will check it today
<enebo[m]>
edipo.federle: probably not... It looks fine
<enebo[m]>
edipo.federle: I just noticed you return null in two places which would return nil out of the Ruby method
<enebo[m]>
Likely those returns are nil but null will cause problems
<enebo[m]>
I put it into a review on the PR
<edipofederle[m]>
True,
<edipofederle[m]>
shosuld be a RubyNil ?
<edipofederle[m]>
s/shosuld/should/
<enebo[m]>
context.nil you can use
<enebo[m]>
Actually this is a good time to bring this up
<enebo[m]>
you call getRuby().getCurrentContext() but at the place you call these new methods you have ThreadContext available
<edipofederle[m]>
but checking on RubyNumeric. java, looks like it is implemented .. not sure why is failing. .
<enebo[m]>
edipo.federle: sorry ... this may sound weird but suddenly we had 13 turkeys outside our house
<enebo[m]>
we live in the city so it is a strange event
<enebo[m]>
edipo.federle: you do not need to solve the ThreadContext thing. I will change it after I land. I notice that aref does not have context as a param and I want to look into it (it is complicated enough I will not ask you to do it)
<enebo[m]>
The general thing about ThreadContext is usually all our methods get it passed in so we do not need to try and get it from Runtime.
<headius>
enebo: I will be reviewing a backlog of issues in JNR and 9.3/2 today
<enebo[m]>
headius: yeah we may want to detarget some of the items still open for 9.3.2 also
<headius>
probably... I have been trying to be better about punting versus detargeting
<headius>
debug gem has been updated with JRuby logic to skip iseq and continuation stuff
<headius>
slowly knocking down these last few gems
<headius>
if we can get io/wait updated for JRuby then most of the net/* stuff can go to gems too
<headius>
I'm going to spin JNR releases based on that so we can see how it feels on master... clearly not doing a release during Thanksgiving week so it will bake for a bit
<byteit101[m]>
headius: responded
<byteit101[m]>
It's a bug/limitation with the current super verification algo in IR that enebo wrote
<headius>
aha
<enebo[m]>
I added a comment. I am not sure if we should try and fix this issue
<headius>
I see the tricky part of this now
<headius>
so you think we should punt because it would not be valid in Java to do two super calls (which is what is getting kicked out) so we are within our rights to reject such forms in Ruby
<enebo[m]>
We can do flow analysis and verify super is not called more than once
<headius>
it is a regression of behavior though, yes?
<headius>
a regression to support newer better functionality but a regression nonetheless
<enebo[m]>
but an if stmt in Ruby can be anything
<headius>
oh I see we are rejecting it because we see two supers
<headius>
not JVM rejecting it
<enebo[m]>
So I am wondering how likely it will be something which is not depending on the ctor being done enough to have self
<enebo[m]>
yeah we intentionally detect this
<byteit101[m]>
enebo:
<byteit101[m]>
> if test since it cannot use self.
<byteit101[m]>
it can use self, but only the ruby half of self, not the java half of self
<enebo[m]>
byteit101: yeah but this is quite strange thing to do at this point in a Ruby object which is underpinned by Java
<enebo[m]>
Perhaps looking at in-params to setup arguments to super
<byteit101[m]>
We need to split the initialize, and as long as java can have the two halfs, in theory we could do anything, but the simple case of 1 super is trivial
<enebo[m]>
but people can work around that
<enebo[m]>
yeah the mechanics of splitting is another complication too
<enebo[m]>
Obviously we can support that too
<enebo[m]>
I just think bang for buck we have the right impl and this can largely be worked-around
<enebo[m]>
Perhaps a better error message (and possibly link to wiki?)
<byteit101[m]>
> not JVM rejecting it
<byteit101[m]>
headius: > oh I see we are rejecting it because we see two supers
<byteit101[m]>
correct
<byteit101[m]>
> Perhaps looking at in-params to setup arguments to super
<byteit101[m]>
we used to do that, but that prohibits new arguments, which is why I had to change it for the concrete stuff
<enebo[m]>
logically we can support anything which only tries to invoke super a single time (and we can prove that statically) but that also mean we need to have before/after codes for each super and generate something a lot more complicated
<byteit101[m]>
args = if ... end
<enebo[m]>
byteit101: yeah
<byteit101[m]>
super *args #something like that
<enebo[m]>
With infnite resources this might be a fun project for someone but it is not difficult to work around as a limitation so I think maybe we improve error message with a wiki link?
<byteit101[m]>
I think I was going to improve the error messages via code review, but I think that was a sudden "lets just merge it as-is" and that never happened
<enebo[m]>
if (foo); if (bar); super; else; super; else; super; end
<enebo[m]>
heh I am missing an end but it is a deep hole
<byteit101[m]>
where is project loom when you need it?
<enebo[m]>
we do have an algorithm for this sort of thing but you have to generate a CFG to perform it
<enebo[m]>
We only do this on the startup instrs
<enebo[m]>
which again is doable to switch to full but another complcication
<enebo[m]>
byteit101: if you can add a better error message as PR that would be great.
<byteit101[m]>
I can, but I may take some time as I'm utterly swamped until next week
<enebo[m]>
byteit101: this is not a big deal timewise as we probably found the lone user who did this besides possibly you
<enebo[m]>
doing multiple super is pretty rare in Ruby itself
<byteit101[m]>
I've been finding lots of exciting bugs everywhere I look recently. Just the past 48 hours I've found a Java compiler bug with normal Java code and a code-smuggling vulnerability by accident in a product I shall not name until they get back to me
<byteit101[m]>
but I'll put this on my to-do list next week