On Fri, 26 Apr 2024 09:42:06 GMT, Claes Redestad wrote:
>> Splitting out the ASM-based version from #18690 to push that first under the
>> JBS (to help backporting). Keeping #18690 open to rebase and follow-up on
>> this as a subtask. See discussion in that #18690 for more details,
>>
On Fri, 26 Apr 2024 08:45:45 GMT, Claes Redestad wrote:
>> Splitting out the ASM-based version from #18690 to push that first under the
>> JBS (to help backporting). Keeping #18690 open to rebase and follow-up on
>> this as a subtask. See discussion in that #18690 for more details,
>>
> Splitting out the ASM-based version from #18690 to push that first under the
> JBS (to help backporting). Keeping #18690 open to rebase and follow-up on
> this as a subtask. See discussion in that #18690 for more details, discussion
> and motivation for this.
Claes Redestad has updated the
On Fri, 26 Apr 2024 08:45:45 GMT, Claes Redestad wrote:
>> Splitting out the ASM-based version from #18690 to push that first under the
>> JBS (to help backporting). Keeping #18690 open to rebase and follow-up on
>> this as a subtask. See discussion in that #18690 for more details,
>>
On Thu, 25 Apr 2024 19:53:46 GMT, Claes Redestad wrote:
>> Splitting out the ASM-based version from #18690 to push that first under the
>> JBS (to help backporting). Keeping #18690 open to rebase and follow-up on
>> this as a subtask. See discussion in that #18690 for more details,
>>
> Splitting out the ASM-based version from #18690 to push that first under the
> JBS (to help backporting). Keeping #18690 open to rebase and follow-up on
> this as a subtask. See discussion in that #18690 for more details, discussion
> and motivation for this.
Claes Redestad has updated the
On Fri, 26 Apr 2024 02:36:22 GMT, Chen Liang wrote:
> Also a side note for backport: ClassFileDumper exists only since JDK 21, so
> for earlier backports you need to use an alternative dumping method or remove
> dumping ability.
Yes, original code used ProxyClassDumper, which was
On Fri, 26 Apr 2024 03:14:54 GMT, Mandy Chung wrote:
>> Claes Redestad has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Remove accidental use of java.lang.classfile
>
>
On Thu, 25 Apr 2024 19:53:46 GMT, Claes Redestad wrote:
>> Splitting out the ASM-based version from #18690 to push that first under the
>> JBS (to help backporting). Keeping #18690 open to rebase and follow-up on
>> this as a subtask. See discussion in that #18690 for more details,
>>
On Thu, 25 Apr 2024 19:53:46 GMT, Claes Redestad wrote:
>> Splitting out the ASM-based version from #18690 to push that first under the
>> JBS (to help backporting). Keeping #18690 open to rebase and follow-up on
>> this as a subtask. See discussion in that #18690 for more details,
>>
On Wed, 24 Apr 2024 19:13:43 GMT, Claes Redestad wrote:
>> This patch suggests a workaround to an issue with huge SCF MH expression
>> trees taking excessive JIT compilation resources by reviving (part of) the
>> simple bytecode-generating strategy that was originally available as an
>>
On Thu, 25 Apr 2024 19:53:46 GMT, Claes Redestad wrote:
>> Splitting out the ASM-based version from #18690 to push that first under the
>> JBS (to help backporting). Keeping #18690 open to rebase and follow-up on
>> this as a subtask. See discussion in that #18690 for more details,
>>
On Thu, 25 Apr 2024 16:46:25 GMT, Chen Liang wrote:
>> Claes Redestad has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Remove accidental use of java.lang.classfile
>
> src/java.base/share/classes/java/lang/invoke/StringConcatFactory.java
> Splitting out the ASM-based version from #18690 to push that first under the
> JBS (to help backporting). Keeping #18690 open to rebase and follow-up on
> this as a subtask. See discussion in that #18690 for more details, discussion
> and motivation for this.
Claes Redestad has updated the
On Thu, 25 Apr 2024 14:15:56 GMT, Claes Redestad wrote:
> Splitting out the ASM-based version from #18690 to push that first under the
> JBS (to help backporting). Keeping #18690 open to rebase and follow-up on
> this as a subtask. See discussion in that #18690 for more details, discussion
>
Splitting out the ASM-based version from #18690 to push that first under the
JBS (to help backporting). Keeping #18690 open to rebase and follow-up on this
as a subtask. See discussion in that #18690 for more details, discussion and
motivation for this.
-
Commit messages:
- Adapt
On Wed, 24 Apr 2024 10:05:27 GMT, Aleksey Shipilev wrote:
>>> I really wish this change was not done with ClassFile API, but with a
>>> simple bundled ASM, so it would be easily backportable, if we decide to. It
>>> does not look like CFA buys us a lot here readability/complexity wise:
>>>
> This patch suggests a workaround to an issue with huge SCF MH expression
> trees taking excessive JIT compilation resources by reviving (part of) the
> simple bytecode-generating strategy that was originally available as an
> all-or-nothing strategy choice.
>
> Instead of reintroducing a
On Wed, 24 Apr 2024 10:08:42 GMT, Claes Redestad wrote:
>> This patch suggests a workaround to an issue with huge SCF MH expression
>> trees taking excessive JIT compilation resources by reviving (part of) the
>> simple bytecode-generating strategy that was originally available as an
>>
On Wed, 24 Apr 2024 10:08:42 GMT, Claes Redestad wrote:
>> This patch suggests a workaround to an issue with huge SCF MH expression
>> trees taking excessive JIT compilation resources by reviving (part of) the
>> simple bytecode-generating strategy that was originally available as an
>>
> This patch suggests a workaround to an issue with huge SCF MH expression
> trees taking excessive JIT compilation resources by reviving (part of) the
> simple bytecode-generating strategy that was originally available as an
> all-or-nothing strategy choice.
>
> Instead of reintroducing a
On Wed, 24 Apr 2024 10:01:47 GMT, Claes Redestad wrote:
> > I really wish this change was not done with ClassFile API, but with a
> > simple bundled ASM, so it would be easily backportable, if we decide to. It
> > does not look like CFA buys us a lot here readability/complexity wise:
> >
On Wed, 24 Apr 2024 09:57:42 GMT, Claes Redestad wrote:
>> This patch suggests a workaround to an issue with huge SCF MH expression
>> trees taking excessive JIT compilation resources by reviving (part of) the
>> simple bytecode-generating strategy that was originally available as an
>>
On Sun, 14 Apr 2024 14:33:26 GMT, Claes Redestad wrote:
>> What are the scenarios which had regressions?
>> Given the conservative growth for StringBuilder, it surprises me a bit that
>> any scenario would regress.
>
> I took a second look and it turns out that there were neither regressions
> This patch suggests a workaround to an issue with huge SCF MH expression
> trees taking excessive JIT compilation resources by reviving (part of) the
> simple bytecode-generating strategy that was originally available as an
> all-or-nothing strategy choice.
>
> Instead of reintroducing a
On Thu, 18 Apr 2024 14:50:30 GMT, Claes Redestad wrote:
>> This patch suggests a workaround to an issue with huge SCF MH expression
>> trees taking excessive JIT compilation resources by reviving (part of) the
>> simple bytecode-generating strategy that was originally available as an
>>
On Thu, 18 Apr 2024 14:50:30 GMT, Claes Redestad wrote:
>> This patch suggests a workaround to an issue with huge SCF MH expression
>> trees taking excessive JIT compilation resources by reviving (part of) the
>> simple bytecode-generating strategy that was originally available as an
>>
On Mon, 22 Apr 2024 08:59:33 GMT, Claes Redestad wrote:
> @mlchung @asotona: Alan asked me to use the ClassFile API here. As it's only
> used in what's effectively a slow path it shouldn't be blocked by the startup
> investigations we're doing there, right?
I agree that this should not be
On Thu, 18 Apr 2024 14:50:30 GMT, Claes Redestad wrote:
>> This patch suggests a workaround to an issue with huge SCF MH expression
>> trees taking excessive JIT compilation resources by reviving (part of) the
>> simple bytecode-generating strategy that was originally available as an
>>
> This patch suggests a workaround to an issue with huge SCF MH expression
> trees taking excessive JIT compilation resources by reviving (part of) the
> simple bytecode-generating strategy that was originally available as an
> all-or-nothing strategy choice.
>
> Instead of reintroducing a
> This patch suggests a workaround to an issue with huge SCF MH expression
> trees taking excessive JIT compilation resources by reviving (part of) the
> simple bytecode-generating strategy that was originally available as an
> all-or-nothing strategy choice.
>
> Instead of reintroducing a
> This patch suggests a workaround to an issue with huge SCF MH expression
> trees taking excessive JIT compilation resources by reviving (part of) the
> simple bytecode-generating strategy that was originally available as an
> all-or-nothing strategy choice.
>
> Instead of reintroducing a
On Fri, 12 Apr 2024 15:06:36 GMT, Chen Liang wrote:
>> 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
> This patch suggests a workaround to an issue with huge SCF MH expression
> trees taking excessive JIT compilation resources by reviving (part of) the
> simple bytecode-generating strategy that was originally available as an
> all-or-nothing strategy choice.
>
> Instead of reintroducing a
On Sat, 13 Apr 2024 17:54:54 GMT, Brett Okken wrote:
>> Possibly. I tried a few simple variants that initialized the `StringBuilder`
>> capacity at various guesses, such as sum of constant sizes + some factor
>> based on args, but across a diverse set of micros that gives both some wins
>>
On Fri, 12 Apr 2024 10:19:27 GMT, Claes Redestad wrote:
>> src/java.base/share/classes/java/lang/invoke/StringConcatFactory.java line
>> 1430:
>>
>>> 1428: cb.new_(STRING_BUILDER);
>>> 1429: cb.dup();
>>> 1430:
> This patch suggests a workaround to an issue with huge SCF MH expression
> trees taking excessive JIT compilation resources by reviving (part of) the
> simple bytecode-generating strategy that was originally available as an
> all-or-nothing strategy choice.
>
> Instead of reintroducing a
On Fri, 12 Apr 2024 14:26:04 GMT, Chen Liang wrote:
>> Claes Redestad has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> @liach feedback
>
> src/java.base/share/classes/java/lang/invoke/StringConcatFactory.java line
> 1406:
>
>> 1404:
On Fri, 12 Apr 2024 14:57:45 GMT, Claes Redestad 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] !=
On Fri, 12 Apr 2024 14:53:58 GMT, Chen Liang wrote:
>> This patch suggests a workaround to an issue with huge SCF MH expression
>> trees taking excessive JIT compilation resources by reviving (part of) the
>> simple bytecode-generating strategy that was originally available as an
>>
On Tue, 9 Apr 2024 12:01:49 GMT, Claes Redestad wrote:
> This patch suggests a workaround to an issue with huge SCF MH expression
> trees taking excessive JIT compilation resources by reviving (part of) the
> simple bytecode-generating strategy that was originally available as an
>
On Fri, 12 Apr 2024 14:32:05 GMT, Chen Liang wrote:
>> This patch suggests a workaround to an issue with huge SCF MH expression
>> trees taking excessive JIT compilation resources by reviving (part of) the
>> simple bytecode-generating strategy that was originally available as an
>>
On Fri, 12 Apr 2024 13:44:23 GMT, Rémi Forax wrote:
> One class per arity + value classes can be a good combo ?
Not sure value classes matter here? We would need one static instance per call
site holding the constants. Trickier for performance is the potential for
profile pollution between
On Tue, 9 Apr 2024 12:01:49 GMT, Claes Redestad wrote:
> This patch suggests a workaround to an issue with huge SCF MH expression
> trees taking excessive JIT compilation resources by reviving (part of) the
> simple bytecode-generating strategy that was originally available as an
>
On Tue, 9 Apr 2024 12:01:49 GMT, Claes Redestad wrote:
> This patch suggests a workaround to an issue with huge SCF MH expression
> trees taking excessive JIT compilation resources by reviving (part of) the
> simple bytecode-generating strategy that was originally available as an
>
On Fri, 12 Apr 2024 11:41:17 GMT, Thomas Stuefe wrote:
> Yes, we are concerned with that, especially for a possible future where
> Lilliput is the sole default. Atm we can address about 4 million classes.
> There are thoughts about making this number of classes infinite, but if
> possible we
On Fri, 12 Apr 2024 10:07:48 GMT, Claes Redestad wrote:
> I guess Lilliput adds some hard or soft limit on the number of classes loaded?
Yes, we are concerned with that, especially for a possible future where
Lilliput is the sole default. Atm we can address about 4 million classes. There
are
On Fri, 12 Apr 2024 03:16:58 GMT, Brett Okken wrote:
>> This patch suggests a workaround to an issue with huge SCF MH expression
>> trees taking excessive JIT compilation resources by reviving (part of) the
>> simple bytecode-generating strategy that was originally available as an
>>
On Fri, 12 Apr 2024 06:34:32 GMT, Thomas Stuefe 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
>
On Tue, 9 Apr 2024 12:01:49 GMT, Claes Redestad wrote:
> This patch suggests a workaround to an issue with huge SCF MH expression
> trees taking excessive JIT compilation resources by reviving (part of) the
> simple bytecode-generating strategy that was originally available as an
>
On Tue, 9 Apr 2024 12:01:49 GMT, Claes Redestad wrote:
> There are a few trade-offs at play here which influence the choice of
> threshold. The simple high arity strategy will for example not see any reuse
> of LambdaForms but strictly always generate a class per indy callsite, which
> means
On Tue, 9 Apr 2024 12:01:49 GMT, Claes Redestad wrote:
> This patch suggests a workaround to an issue with huge SCF MH expression
> trees taking excessive JIT compilation resources by reviving (part of) the
> simple bytecode-generating strategy that was originally available as an
>
On Tue, 9 Apr 2024 12:01:49 GMT, Claes Redestad wrote:
> This patch suggests a workaround to an issue with huge SCF MH expression
> trees taking excessive JIT compilation resources by reviving (part of) the
> simple bytecode-generating strategy that was originally available as an
>
This patch suggests a workaround to an issue with huge SCF MH expression trees
taking excessive JIT compilation resources by reviving (part of) the simple
bytecode-generating strategy that was originally available as an all-or-nothing
strategy choice.
Instead of reintroducing a binary
54 matches
Mail list logo
