22:33 <chrisseaton[m]> Hello. I'm looking at general ideas around Ruby boxing. Why do you disable the unboxing pass by default? Does it have some drawbacks?

23:36 <headius[m]> it doesn't deopt

23:41 <chrisseaton[m]> Ah the old problem of not being able to read real JVM local variables easily.

23:42 <headius[m]> well, mostly we just have never implemented deopt at the bytecode level

23:47 <headius[m]> Nashorn did it, and we know how to do it, but it has not been a priority

23:49 <chrisseaton[m]> Yeah their deoptimisation exceptions I remember

23:49 <headius[m]> enebo, kares: this is my new favorite fix for the JDK classloader bug, let me know how you feel about it: https://github.com/jruby/jruby/pull/6273

23:51 <headius[m]> chrisseaton: we'll do it if forced to, but with the continued improvements in escape analysis and value types I'm hoping we won't have to

23:53 <chrisseaton[m]> It also turns basic operators into simple arithmetic instructions in the IR though, so I guess it must also relieve pressure on the JVM's inliner.

23:54 <headius[m]> I'm sure it does

23:55 <headius[m]> however simple operators would need to be padded with range checks or use Math.*exact calls which adds much of that pressure back

23:56 <headius[m]> not to mention the deopt exception handling and frame reconstitution logic, which would be a large blob of code that's (ideally) only used in rare cases

23:58 <chrisseaton[m]> I think the exact calls can be substituted during graph building, so aren't too bad

23:59 <headius[m]> a hybrid approach I've considered is to use a small carrier object that holds both the native long bits and an object reference