On Thu, 22 Aug 2024 11:50:02 GMT, Shaojin Wen <d...@openjdk.org> wrote:
> This is a follow-up to PR #20273, which improves performance when the number > of parameters exceeds 20. > > When the number of parameters is large, the possibility of reuse will be > lower, so we can use the static concat method and write the length and coder > directly into the bytecode to solve the performance regression problem. - Can we try to optimize the default generation shape further before we reach for this sort of specialization? - How well-motivated is it to increase complexity to optimize huge expressions, which can be assumed to be rare and less likely to be part of the critical path? - If we do this I think we need to have a separate control flag than `inlineThreshold` - Perhaps `hardCoded` would better describe what's going on than `static`: we're hard-coding all the constants and the values derived from them into the concat bytecode. As a result the concatenator becomes `static`, but that's is a side-effect of hard-coding rather than injecting constants. - Trivial optimizations such as passing `true` to `methodType` and using `MethodTypeDescImpl.ofValidated` could be split out to a separate PR to keep this patch cleaner and easier to review/discuss. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20675#issuecomment-2308789379
