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

[Chen Liang]

On Fri, 12 Apr 2024 14:57:45 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/invoke/StringConcatFactory.java line 1437:
>> 
>>> 1435:                         for (int c = 0; c < args.parameterCount(); c++) {
>>> 1436:                             if (constants[c] != null) {
>>> 1437:                                 cb.ldc(constants[c]);
>> 
>> I think for Remi's approach, we change:
>> 1. Insert an extra String array (maybe need a way to mark it stable?) arg representing constants
>> 2. Change this ldc into aload + aaload (or List.get if we use immutable List)
>> 3. Call `bindTo(constantStrings)` on the resulting MH
>> 
>> This approach can significantly reduce the number of classes spinned instead of generating one class per constant array; might need to measure performance to see if this is a good tradeoff
>> 
>> Oh, I just noticed that we need to erase everything to the generic method type. I think Remi's "value class" means there's no overhead for converting primitives into wrappers in this conversion to generic method type.
>
> I'd prefer considering such optimizations as follow-ups. We need to think about where to define such shared classes in a way that considers the full lifecycle, facilitates class unloading (one cache per classloader?) while still getting good reuse.

I think `Invokers` might be a good place. Its lifetime is bound to its MT, and MT already handles class unloading well. If we are doing erased then a plain array suffices.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18690#discussion_r1562686793