On Mon, 16 Sep 2024 19:11:23 GMT, Claes Redestad <redes...@openjdk.org> wrote:
>> 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.) I will leave this hash computation mechanism whole as is; table initialization and small table optimizations can come in other patches later. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20667#discussion_r1767398487
