Removing some integers from constant pool

gistfile1.txt

diff --git a/src/vm/jvm/QAST/Compiler.nqp b/src/vm/jvm/QAST/Compiler.nqp
index 6de7ab6..9da7b46 100644
--- a/src/vm/jvm/QAST/Compiler.nqp
+++ b/src/vm/jvm/QAST/Compiler.nqp
@@ -4822,7 +4822,14 @@ class QAST::CompilerJAST {
         my $idx    := nqp::scgetobjidx($sc, $val);
         my $il     := JAST::InstructionList.new();
         $il.append(JAST::PushSVal.new( :value($handle) ));
-        $il.append(JAST::PushIndex.new( :value($idx) ));
+        if $idx >= 32768 {
+            $il.append(JAST::PushIndex.new( :value($idx-32768) ));
+            $il.append(JAST::PushIndex.new( :value(32768) ));
+            $il.append($IADD);
+        }
+        else {
+            $il.append(JAST::PushIndex.new( :value($idx) ));
+        }
         $il.append($ALOAD_1);
         $il.append(JAST::InvokeDynamic.new(
             'wval_noa', $TYPE_SMO, [$TYPE_STR, 'I', $TYPE_TC],

Currently the build of rakudo-j dies during stage classfile with 'Classfile too large'. It looks like there are too many constant pool entries (there is a limit at 65536.)

We have a lot of (large) Integers in the constant pool. Most of them are added in multi method as_jast(QAST::WVal $node, :$want) { }.

As a proof of concept I changed the relevant code so that in some cases existing constant pool entries are reused instead of adding a new Integer. That change makes rakudo-j build again. (Rakudo also passes its tests and spectest looks at least reasonable.)

IMHO a clean solution would avoid JAST::PushIndex.new for those Integers completely, but I wasn't able to figure a way to do that, yet. The above code is really only meant to illustrate my idea.