On Sun, 18 Aug 2024 21:36:07 GMT, Shaojin Wen <d...@openjdk.org> wrote:
>> Using ConstantDescs.MTD_void can also solve the bootstrap cycle, good idea, >> I have fixed it > > I think it is worthwhile to optimize the bootstrap scenario with less cost > for other scenarios. Right, which is why we need to balance these microbenchmark speed-ups against any added static footprint and other factors. Going through fewer but less specialized methods can reduce runtime footprint and lead to quicker warmup, for example. Also, @liach pointed out elsewhere the we might be able to avoid many of these `ofDescriptor` calls with optimizations elsewhere, so perhaps let's not go overboard here and re-measure with those optimizations in place as it might make this work less impactful. On a related note: Running micros with `-Xint` and `-XX:TieredStopAtLevel=1` can help indicate whether some optimization will be helpful during startup or not. Often things align well, but sometimes optimizations that help peak performance make interpreted performance worse, and vice versa. If we're optimizing for startup the best is obviously to check on some startup benchmark of choice. A recent example (on Linux): `perf stat -r 50 java -jar benchmarks.jar org.openjdk.bench.java.lang.StringConcatStartup` or simply `make test TEST=micro:StringConcatStartup` FWIW I use this technique all the time to diagnose what we're doing during startup: https://cl4es.github.io/2018/11/23/Investigating-Startup-Using-Bytestacks.html - it has helped me find numerous candidates for startup optimization. Main reason I'm insisting on adding a main method to startup-centric JMH benchmarks. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20611#discussion_r1721077436
