[SPARK-18016][SQL][CATALYST] Code Generation: Constant Pool Limit - State Compaction

[bdrillard]

What changes were proposed in this pull request?

This PR is the part two followup to #18075, meant to address SPARK-18016, Constant Pool limit exceptions. Part 1 implemented NestedClass code splitting, in which excess code was split off into nested private sub-classes of the OuterClass. In Part 2 we address excess mutable state, in which the number of inlined variables declared at the top of the OuterClass can also exceed the constant pool limit.

Here, we modify the addMutableState function in the CodeGenerator to check if the declared state can be easily initialized compacted into an array and initialized in loops rather than inlined and initialized with its own line of code. We identify four types of state that can compacted:

• Primitive state (ints, booleans, etc)
• Object state of like-type without any initial assignment
• Object state of like-type initialized to null
• Object state of like-type initialized to the type's base (no-argument) constructor

With mutable state compaction, at the top of the class we generate array declarations like:

private Object[] references;
private UnsafeRow result;
private org.apache.spark.sql.catalyst.expressions.codegen.BufferHolder holder;
private org.apache.spark.sql.catalyst.expressions.codegen.UnsafeRowWriter rowWriter;
...
private boolean[] mutableStateArray1 = new boolean[12507];
private InternalRow[] mutableStateArray4 = new InternalRow[5268];
private org.apache.spark.sql.catalyst.expressions.codegen.UnsafeArrayWriter[] mutableStateArray5 = new org.apache.spark.sql.catalyst.expressions.codegen.UnsafeArrayWriter[7663];
private java.lang.String[] mutableStateArray2 = new java.lang.String[12477];
private int[] mutableStateArray = new int[42509];
private java.lang.Object[] mutableStateArray6 = new java.lang.Object[30];
private boolean[] mutableStateArray3 = new boolean[10536];

and these arrays are initialized in loops as:

private void init_3485() {
for (int i = 0; i < mutableStateArray3.length; i++) {
mutableStateArray3[i] = false;
}
}

For compacted mutable state, addMutableState returns an array accessor value, which is then referenced in the subsequent generated code.

Note: some state cannot be easily compacted (except without perhaps deeper changes to generating code), as some state value names are taken for granted at the global level during code generation (see CatalystToExternalMap in Objects as an example). For this state, we provide an inline hint to the function call, which indicates that the state should be inlined to the OuterClass. Still, the state we can easily compact manages to reduce the Constant Pool to an tractable size for the wide/deeply nested schemas I was able to test against.

How was this patch tested?

Tested against several complex schema types, also added a test case generating 40,000 string columns and creating the UnsafeProjection.

[bdrillard]

Changes I made here to splitExpressions were to handle instances where the split code method references were still over 64kb. It would seem this problem is addressed by @mgaido91 in #19480, and that implementation is much more thorough, so if that PR gets merged, I'd prefer to rebase against that.

[kiszk]

Thank you for creating a PR for the latest Spark.

I think that it is great to reduce # of constant pool entries. I have one high level comment.
IIUC, this PR always perform mutable state compaction. In other words, mutable states are in arrays.
I am afraid about possible performance degradation due to increasing access cost by putting states in arrays.

What do you think about putting mutable states into arrays (i.e. performing mutable state compaction) only when there are many mutable states or only for certain mutable states that are rarely accessed?
Or, can we say there is no performance degradation due to mutable state compaction?

What do you think?

[bdrillard]

@kiszk You are correct that the current implementation compacts all mutable state (where the state does not have to be explicitly inlined).

To your last question, I'd attempted some analysis of the JVM bytecode of array versus inlined state initialized either through method calls or in loops. I'd posted the experiment and results: https://github.com/bdrillard/bytecode-poc

If Spark has its own benchmarking tools, I'd be happy to use those to compare Catalyst-generated classes further.

To the general question of when we compact state, I think some kind of threshold still does makes sense. It would be best to ensure that the typical code path (for typical Dataset schemas) remains un-impacted by the changes (as was the aim when generating nested classes in #18075).

I've found trying to set a global threshold for when to compact mutable state can be hard. Some state has to be inlined (state that uses parameterized constructors that can't be easily initialized with loops, like the BufferHolder and UnsafeRowWriter). I've found situations where, due to code generator flow, we began by inlining an amount of state that could have been compacted, then started compacting state as after a set threshold, but then began inlining state again that could not be compacted, forcing us over the constant pool limit.

It's difficult to tell when a certain piece of state will be referenced frequently or infrequently. For example, we do know some pieces of primitive mutable state, like global booleans that are part of conditional checks, are initialized globally, assigned once in one method, and then referenced only once in a separate caller method. These are excellent candidates for compaction, since they proliferate very quickly and are, in a sense, "only used once" (declared, initialized, re-assigned in a method, accessed in another method, never used again).

Other pieces of state, like row objects, and JavaBean objects, will be accessed a number of times relative to how many fields they have, which isn't necessarily easy info to retrieve during code generation (we'd have to reflect or do inspection of the initialization code to know how many fields such an object has). But these items are probably still good candidates for compaction in general because of how many of a given type there could be.

I'm inclined to use a threshold against the name/types of the state, rather than a global threshold. Since freshName is always monotonically increasing from 1 for a given variable prefix, we could know when a threshold for state of that type was reached, and when we could begin compacting that type of state, independently/concurrently with the other types of state. Such a scheme would allow us to ensure the usual flow of code-generation remains as it is now, with no state-compaction for typical operations, and then with state-compaction in the more extreme cases that would threaten to blow the Constant Pool limit.

[kiszk]

@bdrillard I remember that we had the similar discussion about benchmarking. Could you see this discussion?

[bdrillard]

@kiszk Ah, thanks for the link back to that discussion. I'll make modifications to the trials for better data.

[mgaido91]

@bdrillard since my PR and other get merged now there are some conflicts, may you please fix them? Thanks.

[cloud-fan]

I'd like to have something like

val wrapper = ctx.addMutableState("UTF8String.IntWrapper", v => s"$v = new UTF8String.IntWrapper();")

[cloud-fan]

ping @bdrillard

[cloud-fan]

@kiszk@maropu any of you wanna take this over? This patch becomes important as we now split codes more aggressively.

[kiszk]

@cloud-fan I want to take this over if possible
cc @maropu

[maropu]

yea, ok @kiszk I'll review your work.

[kiszk]

@cloud-fan Is it better to use this PR? Or, create a new PR?

[kiszk]

ping @cloud-fan

[cloud-fan]

let's create a new PR

[kiszk]

OK, I will create a new PR

[bdrillard]

Thanks for giving this the attention to shepard it on through. I haven't had the time to do the additional coding work necessary to properly benchmark it in the last few weeks. @kiszk, if there are any questions in regards to my earlier implementation as you make/review the second PR, I'm happy to make clarifications and would be able to respond to those in writing quickly.

[cloud-fan]

@bdrillard thanks!

[kiszk]

@bdrillard@cloud-fan@maropu
I created and ran a synthetic benchmark program. I think that to use an array for a compaction (as shown in Array) is slower than to use scalar instance variables (as shown in Vars). In the following my case, 20% slower in the best time.

Thus, I would like to use an approach to create inner classes to keep in scalar instance variables.
WDYT? Any comments are very appreciated.

Here are Test.java and myInsntance.py that I used.

$ cat /proc/cpuinfo | grep "model name" | uniq
model name	: Intel(R) Xeon(R) CPU E5-2667 v3 @ 3.20GHz
$ java -version
openjdk version "1.8.0_131"
OpenJDK Runtime Environment (build 1.8.0_131-8u131-b11-2ubuntu1.16.04.3-b11)
OpenJDK 64-Bit Server VM (build 25.131-b11, mixed mode)
$ python myInstance.py > MyInstance.java && javac Test.java && java Test
Result(us): Array
0: 145333.227
1: 144288.262
2: 144233.871
3: 144536.350
4: 144503.269
5: 144836.117
6: 144448.053
7: 144744.725
8: 144688.652
9: 144727.823
10: 144447.789
11: 144500.638
12: 144641.592
13: 144464.106
14: 144518.914
15: 144844.639
16: 144780.464
17: 144617.363
18: 144463.271
19: 144508.170
20: 144929.451
21: 144529.697
22: 144273.167
23: 144362.926
24: 144296.854
25: 144398.665
26: 144490.813
27: 144435.732
28: 144675.997
29: 144483.581
BEST: 144233.871000, AVG: 144566.806
Result(us): Vars
0: 120375.384
1: 119800.238
2: 119822.842
3: 119830.761
4: 119836.781
5: 120185.751
6: 120208.140
7: 120274.925
8: 120112.109
9: 120082.120
10: 120063.456
11: 120112.493
12: 120144.937
13: 119964.356
14: 119941.633
15: 119825.758
16: 119677.506
17: 119833.236
18: 119749.781
19: 119723.932
20: 120197.394
21: 120052.820
22: 120006.650
23: 119939.335
24: 119857.469
25: 120176.229
26: 120153.605
27: 120345.581
28: 120163.129
29: 120038.673
BEST: 119677.506, AVG: 120016.567

Small MyInstance.java (N = 16, M = 4)

class MyInstance {
final int N = 16;
int[] instance = new int[N];
void accessArrays00000() {
instance[8] = instance[0];
instance[9] = instance[1];
instance[10] = instance[2];
instance[11] = instance[3];
}
void accessArrays00001() {
instance[12] = instance[4];
instance[13] = instance[5];
instance[14] = instance[6];
instance[15] = instance[7];
}
void accessArrays00002() {
instance[0] = instance[8];
instance[1] = instance[9];
instance[2] = instance[10];
instance[3] = instance[11];
}
void accessArrays00003() {
instance[4] = instance[12];
instance[5] = instance[13];
instance[6] = instance[14];
instance[7] = instance[15];
}
void accessArray() {
accessArrays00000();
accessArrays00001();
accessArrays00002();
accessArrays00003();
}
int instance00000;
int instance00001;
int instance00002;
int instance00003;
int instance00004;
int instance00005;
int instance00006;
int instance00007;
int instance00008;
int instance00009;
int instance00010;
int instance00011;
int instance00012;
int instance00013;
int instance00014;
int instance00015;
void accessVars00000() {
instance00008 = instance00000;
instance00009 = instance00001;
instance00010 = instance00002;
instance00011 = instance00003;
}
void accessVars00001() {
instance00012 = instance00004;
instance00013 = instance00005;
instance00014 = instance00006;
instance00015 = instance00007;
}
void accessVars00002() {
instance00000 = instance00008;
instance00001 = instance00009;
instance00002 = instance00010;
instance00003 = instance00011;
}
void accessVars00003() {
instance00004 = instance00012;
instance00005 = instance00013;
instance00006 = instance00014;
instance00007 = instance00015;
}
void accessVars() {
accessVars00000();
accessVars00001();
accessVars00002();
accessVars00003();
}
}

[viirya]

I'd prefer inner class approach.

[cloud-fan]

You are comparing array vs member variables, can we compare array vs inner class member variable? And too many classes will have overhead on the classloader, we should test some extreme cases like 1 million variables.

[kiszk]

@cloud-fan you are right, I am updating benchmark program and results.
I realized that we still have limitation of constant pool entries at extreme cases in both approaches .

When we use an array approach, a global variable will be accessed by~ this.globalVar[55555]. Here is a bytecode sequence. Each access to an array element (index is greater than 32768 since sipush for 0 to 32767 do not use constant pool entry) requires one constant pool entry.
While we reduce one constant pool entry for global variable, we require one constant pool entry.

When we use an inner class approach, we still require constant pool entry for accessing instance variables (e.g. `this.inner001.globalVar55555) in one class.

@bdrillard how did your implementation (probably around here) avoid this issue?

This is because it is not necessary to split methods to access instance variables if method size is not large. As a result, these usages of constant pool entries may cause 64K constant pool entries problem again.

WDYT? cc @viirya@maropu

aload 0 // load this
getfield [constant pool index] // load this.globalVar
ldc [constant pool index] // load 55555 from constant pool and push it
iaload

Using an array

class Foo {
int[] globalVars = new int[1024000];
void apply0(InternalRow i) {
globalVars[32768] = 1;
globalVars[32769] = 1;
...
}
void apply1(InternalRow i) {
globalVars[65535] = 1;
globalVars[65536] = 1;
...
}
void apply2(InternalRow i) {
...
globalVars[100000] = 1; // 100000 - 32768 > 65535 i.e. may cause an constant pool entry overflow
...
}
void apply(InternalRow i) {
globalVars[0] = 1;
globalVars[1] = 1;
...
apply0(i);
apply1(i);
apply2(i);
}
}

Using global variables

class Foo {
int globalVars0;
int globalVars1;
...
int globalVars32768;
int globalVars32769;
...
void apply0(InternalRow i) {
globalVars32768 = 1; // 32768 * 2 > 65535 i.e may cause an constant pool entry overflow
globalVars32769 = 1;
...
}
void apply(InternalRow i) {
globalVars0 = 1;
globalVars1 = 1;
...
apply0(i);
}
}

[cloud-fan]

Each access to an array element requires one constant pool entry.

what do you mean by this? using array can't reduce constant pool size at all?

[kiszk]

what do you mean by this? using array can't reduce constant pool size at all?

Not at all. If array index for an access is less than 32768 (e.g. a[30000]), we can reduce constant pool size since constant pool entry is not required (iconst_?, bipush, or sipush java bytecode is used).
However, when array index for an access is greater than 32767 (e.g. a[40000]), we cannot reduce constant pool size since the access requires constant pool entry. This is because integer constant of 32768 or greater uses ldc java bytecode instruction [ref][ref].

In summary, the followings are # of constant pool entries to be used for accessing an entry.

• a[0] = 0...a[32767] = 0 : 0
• a[32768] = 0... : 1
• this.globalVar = 0: 3 (1 is for entry, 1 is for field, 1 is for field name)
  Omitted entries for class and type since they are common among global variables

To use an array can make it slow to reach the limit (i.e. 65535), but it would eventually occur in the extreme case.

[mgaido91]

@kiszk thanks for your great analysis. May I have just a couple of additional questions?
1 - In all your tests, which compiler are you using? Because I see that you are linking to the Oracle docs and maybe you are using javac for your tests, but in my tests (made for other cases) I realized that janinoc works a bit differently and what is true for javac may not be for janinoc.
2 - If the problem with array occurs when we go beyond 32767, what about creating many arrays with max size 32767? I see that this is not a definitive solution and still we have some limitations, but dividing the number of constant pool entries by 32767 looks a very good achievement to me.

[viirya]

The hybrid approach sounds reasonable to me. Any special strategy to use to decide which fields are global variables and which are in array?

[viirya]

Btw, can we config the maximum number of global variables?

[viirya]

When we use an inner class approach, we still require constant pool entry for accessing instance variables (e.g. `this.inner001.globalVar55555) in one class.

@kiszk But we still can save the name/type and field name for global variable?

[mgaido91]

@viirya if you take a look at the example I posted, you can see that we are not saving either NameAndType or Fieldref, thus think the only solution to save constant pool entries we have found so far is to use arrays.

What may be interesting IMHO, is to evaluate where we are using a variable. Since when we have a lot of instance variables we are very likely to have also several inner classes (for splitting the methods), I think it would be great if we were able to declare variables which are used only in an inner class in that inner class. Unfortunately, I think also that this is not trivial to achieve at all. @kiszk what do you think?

[viirya]

@mgaido91 Thanks. I looked at the constant pool you posted. It's clear.

Any benefit to declare the variables in the inner classes? Looks like they still occupy constant pool entries?

[mgaido91]

@viirya in general there is no benefit. There will be a benefit if we manage to declare them where they are used, but I am not sure this is feasible. In this way, they do not add any entry to the constant pool.

For instance, if we have a inner class InnerClass1 and we use isNull_11111 only there, if we define isNull_11111 as a variable of InnerClass1 instead of a variable of the outer class we have no entry about it in the outer class.

[cloud-fan]

For the strategy, I'd like to give priority to primitive values to be in flat global variables. We also need to decide the priority between primitive types, according to which type has largest performance difference between flat global variable and array, and which type is used more frequently(may be boolean).

[kiszk]

First of all, I have to share sad news with you.
janino does not use sipush for values from 128 to 32767. Current janino 3.0.7 uses iconst..., bipush, or ldc. javac uses sipush for values from 128 to 32767. In other words, if index is greater than 127, one constant pool is used by bytecode compiled by janino. It should be fixed.

Based on the analysis in the next comment, the array approach still uses less constant pool entry than other approach.

public class Array {
int[] a = new int[1000000];
void access() {
a[5] = 0;
a[6] = 0;
a[127] = 0;
a[128] = 0;
a[1023] = 0;
a[16383] = 0;
a[32767] = 0;
a[32768] = 0;
}
static public void main(String[] argv) {
Array a = new Array();
a.access();
}
}

 void access();
descriptor: ()V
flags:
Code:
stack=3, locals=1, args_size=1
0: aload_0
1: getfield #12 // Field a:[I
4: iconst_5
5: iconst_0
6: iastore
7: aload_0
8: getfield #12 // Field a:[I
11: bipush 6
13: iconst_0
14: iastore
15: aload_0
16: getfield #12 // Field a:[I
19: bipush 127
21: iconst_0
22: iastore
23: aload_0
24: getfield #12 // Field a:[I
27: ldc #13 // int 128
29: iconst_0
30: iastore
31: aload_0
32: getfield #12 // Field a:[I
35: ldc #14 // int 1023
37: iconst_0
38: iastore
39: aload_0
40: getfield #12 // Field a:[I
43: ldc #15 // int 16383
45: iconst_0
46: iastore
47: aload_0
48: getfield #12 // Field a:[I
51: ldc #16 // int 32767
53: iconst_0
54: iastore
55: aload_0
56: getfield #12 // Field a:[I
59: ldc #17 // int 32768
61: iconst_0
62: iastore
63: return
Constant pool:
#1 = Utf8 Array
#2 = Class #1 // Array
#9 = Utf8 a
#10 = Utf8 [I
#11 = NameAndType #9:#10 // a:[I
#12 = Fieldref #2.#11 // Array.a:[I
#13 = Integer 128
#14 = Integer 1023
#15 = Integer 16383
#16 = Integer 32767
#17 = Integer 32768

[kiszk]

Next, I analyzed usage of constant pool entries and java bytecode ops using janinoc. The summary is as follows:

array[4] : 6 + 0 * n entries, 6-8 java bytecode ops / read access
outerInstance: 3 + 3 * n entries, 5 java bytecode ops / read access
innerInsntace: 9 + 3 * n entries, 6 java bytecode ops / read access

Source program

public class CP {
int[] a = new int[1000000];
int globalVar0;
int globalVar1;
private Inner inner = new Inner();
private class Inner {
int nestedVar0;
int nestedVar1;
}
void access() {
a[4] = 0;
a[5] = 0;
globalVar0 = 0;
globalVar1 = 0;
inner.nestedVar0 = 0;
inner.nestedVar1 = 0;
}
static public void main(String[] argv) {
CP cp = new CP();
cp.access();
}
}

Java bytecode

 void access();
descriptor: ()V
Code:
stack=3, locals=1, args_size=1
0: aload_0
1: getfield #12 // Field a:[I
4: iconst_4
5: iconst_0
6: iastore
7: aload_0
8: getfield #12 // Field a:[I
11: iconst_5
12: iconst_0
13: iastore
14: aload_0
15: iconst_0
16: putfield #16 // Field globalVar0:I
19: aload_0
20: iconst_0
21: putfield #19 // Field globalVar1:I
24: aload_0
25: getfield #23 // Field inner:LCP$Inner;
28: iconst_0
29: putfield #28 // Field CP$Inner.nestedVar0:I
32: aload_0
33: getfield #23 // Field inner:LCP$Inner;
36: iconst_0
37: putfield #31 // Field CP$Inner.nestedVar1:I
40: return

Constant pool

 #1 = Utf8 CP
#2 = Class #1 // CP
#9 = Utf8 a
#10 = Utf8 [I
#11 = NameAndType #9:#10 // a:[I
#12 = Fieldref #2.#11 // CP.a:[I
#13 = Utf8 globalVar0
#14 = Utf8 I
#15 = NameAndType #13:#14 // globalVar0:I
#16 = Fieldref #2.#15 // CP.globalVar0:I
#17 = Utf8 globalVar1
#18 = NameAndType #17:#14 // globalVar1:I
#19 = Fieldref #2.#18 // CP.globalVar1:I
#20 = Utf8 inner
#21 = Utf8 LCP$Inner;
#22 = NameAndType #20:#21 // inner:LCP$Inner;
#23 = Fieldref #2.#22 // CP.inner:LCP$Inner;
#24 = Utf8 CP$Inner
#25 = Class #24 // CP$Inner
#26 = Utf8 nestedVar0
#27 = NameAndType #26:#14 // nestedVar0:I
#28 = Fieldref #25.#27 // CP$Inner.nestedVar0:I
#29 = Utf8 nestedVar1
#30 = NameAndType #29:#14 // nestedVar1:I
#31 = Fieldref #25.#30 // CP$Inner.nestedVar1:I
#32 = Utf8 LineNumberTable
#33 = Utf8 Code
#34 = Utf8 main
#35 = Utf8 ([Ljava/lang/String;)V
#36 = Utf8 <init>
#37 = NameAndType #36:#8 // "<init>":()V
#38 = Methodref #2.#37 // CP."<init>":()V
#39 = NameAndType #7:#8 // access:()V
#40 = Methodref #2.#39 // CP.access:()V
#41 = Methodref #4.#37 // java/lang/Object."<init>":()V
#42 = Integer 1000000
#43 = Utf8 (LCP;)V
#44 = NameAndType #36:#43 // "<init>":(LCP;)V
#45 = Methodref #25.#44 // CP$Inner."<init>":(LCP;)V
#46 = Utf8 Inner
#47 = Utf8 InnerClasses

[kiszk]

Here is a PR for janino to fix a problem regarding sipush.

[viirya]

The PR looks good.

Although it can solve the constant pool pressure, however, I have a question. Does it mean every time a constant falling in short range is used in codes, we increase 1 byte in bytecodes because sipush is followed by two byte value? I'm afraid it may be negative to some cases like many short constants in a java program.

For our usage, will it increase the bytecode size of methods too and break possible limit?

[kiszk]

In int case, the followings are the number of java byte code length for a value

1 byte: -1, 0, 1, 2, 3, 4, 5 (iconst_?)
2 bytes: -128 ~ -2, 6 ~ 127 (bipush)
3 bytes: -32768 ~ -129, 128 ~ 32767 (sipush)
4 or 5 bytes2 or 3 bytes: others (ldc or ldc_w)

[kiszk]

I created and ran another synthetic benchmark program for comparing flat global variables, inner global variables, and array using janinoc for target Java file.
The performance is not much different from the previous one. In summary, the followings are performance results (small number is better).

• 1: array
• 0.90: inner global variables
• 0.73: flat global variables

WDYT? Any comments are very appreciated.

Here are Test.java and myInsntance.py that I used.

$ cat /proc/cpuinfo | grep "model name" | uniq
model name	: Intel(R) Xeon(R) CPU E5-2667 v3 @ 3.20GHz
$ java -version
openjdk version "1.8.0_131"
OpenJDK Runtime Environment (build 1.8.0_131-8u131-b11-2ubuntu1.16.04.3-b11)
OpenJDK 64-Bit Server VM (build 25.131-b11, mixed mode)
$ python myInstance.py > MyInstance.java && janinoc MyInstance.java && javac Test.java && java -Xmx16g Test
Result(us): Array
0: 484251.446
1: 483374.255
2: 483956.692
3: 482498.241
4: 483602.261
5: 482654.567
6: 482896.671
7: 483458.625
8: 483194.317
9: 483387.234
10: 484103.729
11: 483536.493
12: 483790.828
13: 483590.991
14: 483993.488
15: 483455.164
16: 484040.009
17: 483225.837
18: 483126.520
19: 484105.989
20: 484988.935
21: 483766.245
22: 483667.930
23: 483271.499
24: 483071.606
25: 483174.438
26: 483602.474
27: 483210.405
28: 483907.061
29: 483071.964
BEST: 482498.241000, AVG: 483532.530
Result(us): InnerVars
0: 437016.533
1: 436125.481
2: 436360.534
3: 435857.758
4: 436166.243
5: 437089.913
6: 436168.359
7: 435570.397
8: 435550.848
9: 435256.088
10: 435252.679
11: 435765.156
12: 435646.739
13: 437303.993
14: 435315.530
15: 435752.545
16: 434857.606
17: 436776.190
18: 435444.877
19: 435657.649
20: 436248.147
21: 436322.998
22: 437214.262
23: 435907.223
23: 435907.223
24: 435431.025
25: 435274.317
26: 435412.202
27: 435670.321
28: 436494.045
29: 436347.838
BEST: 434857.606, AVG: 435975.250
Result(us): Vars
0: 353983.048
1: 354067.690
2: 353138.178
3: 354093.115
4: 354067.180
5: 352750.571
6: 353672.510
7: 355179.115
8: 353296.750
9: 354522.113
10: 355221.301
11: 355178.172
12: 353859.319
13: 353539.817
14: 352703.352
15: 353923.981
16: 354442.744
17: 355523.145
18: 354849.122
19: 354082.888
20: 354673.504
21: 355526.218
22: 355264.029
23: 355455.492
24: 355520.322
25: 353923.520
26: 353796.600
27: 355021.849
28: 355800.387
29: 353810.567
BEST: 352703.352, AVG: 354362.887

[kiszk]

In #19811, first, I will take a hybrid approach of outer (flat) global variable and arrays. The threshold for # of global variables would be configurable.

I will give high priority to primitive variables to place them at the outer class due to performance.

I think it would be great if we were able to declare variables which are used only in an inner class in that inner class. Unfortunately, I think also that this is not trivial to achieve at all.
It would be great if we could do this. For now, #19811 will not address this.

[viirya]

4 or 5 bytes: others (ldc or ldc_w)

I think ldc is 2 bytes and ldc_w is 3 bytes?

[kiszk]

I think ldc is 2 bytes and ldc_w is 3 bytes?

You are right, thanks, updated.

[kiszk]

Good new is the issue in janino has been quickly fixed. Bad new is no official date to release the next version now.

[AmplabJenkins]

Can one of the admins verify this patch?

[maropu]

@bdrillard can you close this pr?

[bdrillard]

This PR was addressed by #19811, closing this one.