RFR: 8327247: C2 uses up to 2GB of RAM to compile complex string concat in extreme cases

[Claes Redestad]

On Fri, 12 Apr 2024 06:34:32 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> Stupid question maybe, this would be one LambdaForm per argument set? E.g. would two invocations with the same arguments re-use the same LambdaForm?
> 
> I would like to get an understanding of the numbers of classes involved for these solutions, and whether they are bounded. Mostly for Lilliput reason.

Any concat expression sharing the same exact shape will ideally share the same chain of LFs, and many of the intermediary LFs will be shared between concat expressions of all manner of shapes and sizes. On the extreme of an application with one singular, huge expression we might see quite a few LF classes per call site, while the incremental number of classes loaded for an expression whose shape has been visited elsewhere will be none. 

One could guess there is some upper bound based on the number of variant types (7: int, long, float, double, char, boolean, Object) to the power of the highest possible arity (100 - after which javac will start splitting and chaining the indy calls), though since there are some softly referenced caches that the LF editor leans on then in theory it might very well be unbounded. In practice we're bounded by the number of call sites times some factor that depends on how much sharing is going on. Since most expressions are likely to be low arity with high degree of sharing, then a long tail of more complex high arity expressions that might see less degree of sharing the assumption has been that the number of classes loaded per concat will be low.

I guess Lilliput adds some hard or soft limit on the number of classes loaded?

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

PR Comment: https://git.openjdk.org/jdk/pull/18690#issuecomment-2051462197