On Fri, 12 Apr 2024 23:55:01 GMT, Joe Darcy wrote:
> Straightforward test update so it doesn't have to be trivially updated for
> each JDK version.
Thanks for this fix. I recall that I had to add this flag because otherwise
compileSources fails when `@enablePreview` is there. If we can drop
Straightforward test update so it doesn't have to be trivially updated for each
JDK version.
-
Commit messages:
- JDK-8330196: Make java/lang/invoke/defineHiddenClass/BasicTest release
agnostic
Changes: https://git.openjdk.org/jdk/pull/18769/files
Webrev:
> `GZIPInputStream` supports reading data from multiple concatenated GZIP data
> streams since [JDK-4691425](https://bugs.openjdk.org/browse/JDK-4691425). In
> order to do this, after a GZIP trailer frame is read, it attempts to read a
> GZIP header frame and, if successful, proceeds onward to
> `GZIPInputStream` supports reading data from multiple concatenated GZIP data
> streams since [JDK-4691425](https://bugs.openjdk.org/browse/JDK-4691425). In
> order to do this, after a GZIP trailer frame is read, it attempts to read a
> GZIP header frame and, if successful, proceeds onward to
On Fri, 12 Apr 2024 14:53:01 GMT, Viktor Klang wrote:
>> This PR implements Gatherer-inspired encoding of `flatMap` that shows that
>> it is both competitive performance-wise as well as improve correctness.
>>
>> Below is the performance of `Stream::flatMap` (for reference types):
>>
>>
On Fri, 12 Apr 2024 20:58:07 GMT, Naoto Sato wrote:
>> Please review this PR which is a large spec reformatting for
>> _java.text.NumberFormat_ and related subclasses, specifically DecimalFormat
>> and CompactNumberFormat.
>>
>> The motivation for this change was the difficulty of readability
> Please review the updates to support a proposed new
> `-Xlint:dangling-doc-comments` option.
>
> The work can be thought of as in 3 parts:
>
> 1. An update to the `javac` internal class `DeferredLintHandler` so that it
> is possible to specify the appropriately configured `Lint` object when
On Wed, 10 Apr 2024 20:16:50 GMT, Justin Lu wrote:
> Please review this PR which is a large spec reformatting for
> _java.text.NumberFormat_ and related subclasses, specifically DecimalFormat
> and CompactNumberFormat.
>
> The motivation for this change was the difficulty of readability for
> Please review this PR and associated
> [CSR](https://bugs.openjdk.org/browse/JDK-8327703) which introduces strict
> parsing for NumberFormat.
>
> The concrete subclasses that will utilize this leniency value are
> `DecimalFormat` and `CompactNumberFormat`. Strict leniency allows for parsing
On Wed, 3 Apr 2024 10:01:37 GMT, Magnus Ihse Bursie wrote:
>> Jonathan Gibbons has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> adjust call for `saveDanglingDocComments` for enum members
>
> The build changes look okay.
>
> Do you have
> This code makes an intrinsic stub for `Unsafe::setMemory` for x86_64. See
> [this PR](https://github.com/openjdk/jdk/pull/16760) for discussion around
> this change.
>
> Overall, making this an intrinsic improves overall performance of
> `Unsafe::setMemory` by up to 4x for all buffer sizes.
> 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
>>
> This PR implements Gatherer-inspired encoding of `flatMap` that shows that it
> is both competitive performance-wise as well as improve correctness.
>
> Below is the performance of `Stream::flatMap` (for reference types):
>
> Before this PR (on my MacBook, aarch64):
>
> Non-short-circuiting:
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 Wed, 10 Apr 2024 22:55:01 GMT, Joshua Cao wrote:
>> Add notes for `HashMap::putAll()` conservative resizing.
>>
>> Note: everything below this line is from the original change. After
>> discussion, we decided to keep the conservative resizing, but we should add
>> an `@implNote` for the
On Fri, 12 Apr 2024 00:23:33 GMT, Sandhya Viswanathan
wrote:
>> It would not be appropriate to add set memory marks to the existing
>> _jbyte_fill as it is being used by other routines, and the effect of the
>> mark will be very hard to track down (if any).
>>
>> Are you *sure* we want to do
On Fri, 12 Apr 2024 00:14:29 GMT, Sandhya Viswanathan
wrote:
>> Scott Gibbons has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Addressing yet more review comments
>
> src/hotspot/cpu/x86/stubGenerator_x86_64_arraycopy.cpp line 2504:
>
On Fri, 12 Apr 2024 00:25:34 GMT, Sandhya Viswanathan
wrote:
>> src/hotspot/cpu/x86/stubGenerator_x86_64_arraycopy.cpp line 2521:
>>
>>> 2519: const Register byteVal = rdx;
>>> 2520:
>>> 2521: // Propagate byte to full Register
>>
>> The comment refers to lines 2524-2526, please
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
>>
Consider code like:
public class MainClass {
public MainClass() {
System.out.println("Constructor called!");
}
public static void main() {
System.out.println("main called!");
}
}
and compile and run it, with preview enabled, like:
$ javac /tmp/MainClass.java
$
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 Thu, 11 Apr 2024 14:44:32 GMT, Chen Liang wrote:
>> Korov has updated the pull request incrementally with one additional commit
>> since the last revision:
>>
>> Use testNG builtin functionalities and modify the test function name
>
> Keep-alive, maybe people like @viktorklang-ora might
On Mon, 8 Apr 2024 16:47:24 GMT, Paul Sandoz wrote:
>> @PaulSandoz @AlanBateman I've added a commit to this PR which removes the
>> use of Gatherer for Stream::flatMap, but instead implements flatMap for all
>> of the pipelines using the same encoding which Gatherer would use. It seems
>>
> This PR implements Gatherer-inspired encoding of `flatMap` that shows that it
> is both competitive performance-wise as well as improve correctness.
>
> Below is the performance of `Stream::flatMap` (for reference types):
>
> Before this PR:
>
> Benchmark(size) Mode Cnt
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
35 matches
Mail list logo
