On Fri, 19 Nov 2021 05:12:25 GMT, Vicente Romero <vrom...@openjdk.org> wrote:
> It seems like the execution is way faster for these number of slots. I suggested this experiment to split up the concatenations more aggressively to diagnose if we're having an issue here where the performance of the method handle produced by `StringConcatFactory` degrades after some number of arguments compared to a more traditional concatenation (as exemplified by the Lombok valueClass tests). And that seems to be the case. While I haven't analyzed the root cause here (I think it seems likely that the JIT bails out at some point when the MH combinator tree grows too large or more likely too deep (long?)) I'd characterize this is a performance bug in the `StringConcatFactory`. This might be straightforward to address by moving the splitting logic you do here inside `StringConcatFactory`. This should be done as a follow-up. Assuming all you had to do to improve over the current patch was set your local `MAX_INDY_CONCAT_ARG_SLOTS` constant to 20 I think it's fine to put that in - we'll want to look at simplifying the `ObjectMethods` code once `StringConcatFactory` better deals with many arguments anyhow. ------------- PR: https://git.openjdk.java.net/jdk/pull/6403
