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 th
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: https://webrevs.openjdk
> `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 d
> `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 d
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):
>>
>> Before
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 i
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 th
> 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 bin
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] != nu
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
>> all-or-not
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
> all-or-noth
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
>> all-or-not
> 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 suc
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
> all-or-noth
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 dec
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 m
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
> all-or-noth
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 w
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 t
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
>> all-or-no
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
$ ja
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
> thes
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 lo
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
>> very
> 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
> all-or-noth
34 matches
Mail list logo
