RFR: 8338546: Speed up ConstantPoolBuilder::classEntry(ClassDesc) [v2]

[Claes Redestad]

On Sun, 15 Sep 2024 13:22:22 GMT, Chen Liang <liach at openjdk.org> wrote:

>> src/java.base/share/classes/jdk/internal/classfile/impl/Util.java line 372:
>> 
>>> 370:      * }
>>> 371:      * }
>>> 372:      * This is converted to explicit initialization to avoid bootstrap overhead.
>> 
>> Have you measured this to be true and useful? Static array initializers are bulky at a bytecode level so sometimes just generating on the fly carries insignicant overhead. Then the `UtilTest` assertion test wouldn't really be needed.
>
> I measured in bytestacks and the clinit instructions reduced by about 2/3

Yes, you have to pick and evaluate between two trade-offs here: a compact routine to compute the array, or a larger initializer which does less compute. Number of instructions executed in the interpreter is a diagnostic tool since if often hides costs that come from having to store, read, parse and manage bytecode - sometimes twice if this hits the default CDS archive. There's no definite answer, but generally the trend is towards compute getting cheaper and IO/memory getting (relatively) more expensive. So picking a larger representation to avoid some one-off compute might be the wrong trade-off.

(Note that this particular instance is probably negligible either way, I just don't want bytestacks instrumentation to put us down a path where we might ultimately end up worse off. Diagnostics needs to be verified with realistic wall clock measurements. When uncertain: go for simplicity.)

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20667#discussion_r1761723308