<byteit101[m]> headius: if you are referring the the ruby < ruby < java super loop issue, I am available to help debug that
<byteit101[m]> (regarding the "JI one")
<headius> byteit101 yeah that is the last blocker for 9.3 now
<byteit101[m]> I know when I last tried to debug it, I got stuck trying to figure out where the super calls had been registered
lopex has quit [Quit: Connection closed for inactivity]
<headius> I'll be available to work on it tomorrow but whatever you can figure out will help
<headius> enebo: did you say something about a metaspace error recently?
<enebo[m]> headius: I said it in regards to a cI run at some point
<headius> I am seeing a job fail with metaspace errors: https://github.com/jruby/jruby/issues/6800
<headius> neither of the dependencies I updated seem to have any changes related to classloading so I'm not sure what changed
<enebo[m]> perhaps VM resources changed
<headius> it's possible but I have not seen it on other jobs... but you have?
<enebo[m]> no I am not sure. I saw it on one and I think it was travis
<enebo[m]> perhaps meatspace on that job is due to something specific to it?
<headius> this was for rubyspec fast with jit, which does create a lot of classes, but it only failed on 8
<headius> maybe they updated 8 recently and it has different meatspace heuristics now
<enebo[m]> meatspace
<enebo[m]> honestly it is the only thing I can call it now and forever more
<ahorek[m]> I saw the error before dependecy changes, it's related to jit_threshold: 0 / that fast+jit job
<ahorek[m]> maybe it's just OOM, travis jobs have some memory restrictions
<headius> ahorek: but you have not seen something we changed to cause this?
<ahorek[m]> no, I don't think any recent change could cause this
<ahorek[m]> and it doesn't always fail
<headius> as far as I know Travis does not publish their changes very well so this could be any number of causes on their end
<headius> new JDK8 using more memory, reduced memory in the VM, new or additional services taking more memory
<headius> I could bump it up but we are naturally reluctant to do that without an explanation
<headius> we do -XX:MaxMetaspaceSize=512M for mspec runs currently
<ahorek[m]> yeah, that should be high enough, a memory profile could help perhaps?
<headius> hmmm perhaps
<headius> I'll try to run locally with 8 this afternoon and see if I can profile (or if I get the errors myself)
<headius> I'm going to merge those two small dep updates and if we see it on master we'll know something's up
<headius> enebo: pushing one more PR to update a few minor things from CRuby 2.6.8 stdlib
<headius> that will mean we are current on all stdlib, gems, and dependencies except for the rdoc and fileutils issues I have filed
<headius> those might have to update to versions newer than CRuby 2.6.8 if the maintainers are unable or unwilling to release the 2.6.8 diffs as their own gem versions
<headius> so other than the JI issue I think we are just about ready
<enebo[m]> yuck ok
<enebo[m]> we definitely need to update for 2.6.8 stdlib
<enebo[m]> but even if we are slightly newer on some if they won't it probably won't be a big deal
<headius> the rdoc change appears to be a CVE so we have to address that
<headius> the fileutils change just allows it to gracefully handle lchmod raising EOPNOTSUPP which we may or may not propagate the same way
<headius> we are newer on a few others so it is not a huge deal but I wanted to poke these maintainers a bit about not keeping CRuby's copies in line with released gems
<headius> we did get a rexml security update release from @kou so that is resolved
<enebo[m]> yeah
<headius> I seem to be having a problem where milestones don't actually show everything
<headius> the missing one here is the fileutils issue I just filed
<headius> it is marked for 9.3.0.0 but does not show in this list, though the list shows 6 issues instead of 5
<enebo[m]> DEEP AI determined you don't need that one
<enebo[m]> ok I see same thing but what is the little grid thing on the left of the one check box
<enebo[m]> derp just highlighted line
<enebo[m]> we shall see how this runs the guantlet. I need to make more methods in all the branches but lets see this green first
<enebo[m]> LOL that will teach me not to full build
<headius> Hah
<headius> At least it is in a PR
<enebo[m]> I think this will work unless CFG.optimize has a bug and cannot be repeatedly called but so far it looks like it is working
<enebo[m]> rdoc markdown found about 100 of these patterns