@kares not related to this PR but I wonder if adding a single instr to IR which can call Java super would be a longer term solution? The tradeoff would be that all constructors would be immediately JIT compiled but we already are leaning on ASM here so I do not see much of a difference. It would remove having the split interpreter. This is a weirder suggestion than it may appear since IR JIT makes jruby methods but it probably can be repurposed to emit a valid Java constructor.

The other option is to make current JIT capable of compiling the two halves but this is more difficult. temp vars in IR are java locals in JIT so it would require spilling locals into an array? to then pass back in for the second half (or guarantee no temps are accessible across the split). I did attempt to make splitable methods a few years ago so we could split on BBs on huge methods but it was invasive (it did not spill locals but changed all local access to indirect through Object[] temp array). That experiment only ran into large refactoring of JVMViisitor. Conceptually it is a path to synthetic methods which this split logic fits.

The other option is to make current JIT capable of compiling the two halves but this is more difficult.

I still do not understand all of the code but indeed approaching a way to JIT from an IR method seemed a bit impossible (without a massive refactoring of the Java super bits).

Haven't thought about having an instruction for the Java super, sounds weird but at least the JITing would be much simpler (as you said byte-code is already generated in first pass anyways so shoudn't matter). Guess, we will have to attempt something on 9.4 at least. Basically anything to make the performance reasonable - comparable to 9.2.

Haven't thought about having an instruction for the Java super, sounds weird but at least the JITing would be much simpler (as you said byte-code is already generated in first pass anyways so shoudn't matter). Guess, we will have to attempt something on 9.4 at least. Basically anything to make the performance reasonable - comparable to 9.2.

I have considered using Java static call instr in IR so that we can eliminate a few instrs since they end up being a single Java call (or can be). Super is a little weirder but is in the same neighborhood. Temp vars are already all Object so you can see some of the new instrs to support pattern matching already are returning Integer and not Fixnum.

moving this out of draft - have some more work locally to clean things up and at least remove duplication but to keep things minimal for 9.3 this at least avoids the contention issue on Java super calls.

this is now merged and expected to be in 9.3.11.0 and 9.4.4.0

the numbers are still not the same as in 9.2 but the contention issue is handled, for the record here are the numbers for 9.4 (using the script from #7763):

jruby 9.4.3.0 (3.1.4) 2023-06-07 3086960792 OpenJDK 64-Bit Server VM 11.0.14.1+1 on 11.0.14.1+1 +jit [x86_64-linux]

100x RubyList.new elapsed real-time: 40.68082665700058
100x RubyList2.new elapsed real-time: 5.673665171998437
100x ArrayList.new elapsed real-time: 0.16680395399453118

200x RubyList.new elapsed real-time: 88.13843810799881
200x RubyList2.new elapsed real-time: 12.741242688003695
200x ArrayList.new elapsed real-time: 0.18367314200440887

jruby 9.4.4.0-SNAPSHOT (3.1.4) 2023-08-14 cf956f1e53 OpenJDK 64-Bit Server VM 11.0.14.1+1 on 11.0.14.1+1 +jit [x86_64-linux]

100x RubyList.new elapsed real-time: 2.806557794989203
100x RubyList2.new elapsed real-time: 6.87243668200972
100x ArrayList.new elapsed real-time: 0.18653793400153518

200x RubyList.new elapsed real-time: 4.38154152900097
200x RubyList2.new elapsed real-time: 13.899855226991349
200x ArrayList.new elapsed real-time: 0.19196245599596296