> We have a few reports that existing Weak* VarHandle tests are still flaky,
> for example on large AArch64 machines or small RISC-V machines.
>
> The flakiness is intrinsic to the nature of Weak* operations under tests,
> that can spuriously fail. The last attempt to fix these was
> [JDK-81557
Spec refinement, including acting on some feedback received for JDK-8266670:
https://github.com/openjdk/jdk/pull/7445#discussion_r906846794
-
Commit messages:
- JDK-8292576: Improve wording of AccessFlag-related specs
Changes: https://git.openjdk.org/jdk/pull/9912/files
Webrev: ht
On Tue, 16 Aug 2022 15:48:15 GMT, Aleksey Shipilev wrote:
>> We have a few reports that existing Weak* VarHandle tests are still flaky,
>> for example on large AArch64 machines or small RISC-V machines.
>>
>> The flakiness is intrinsic to the nature of Weak* operations under tests,
>> that can
On Tue, 16 Aug 2022 10:23:31 GMT, Julian Waters wrote:
>> Second attempt at resolving
>> [JDK-8292016](https://bugs.openjdk.org/browse/JDK-8292016) with a less
>> intrusive approach this time
>>
>> Side note: While it might be preferred to remove this entirely, other areas
>> of the JDK also
On Wed, 17 Aug 2022 15:31:14 GMT, Roger Riggs wrote:
> Revised test to check and close all of the streams used in the pipeline.
>
> The test now checks the content length and closes each stdout and stderr
> stream.
>
> The previous technique to redirect stderr to stdout was ineffective because
On Wed, 17 Aug 2022 15:31:14 GMT, Roger Riggs wrote:
> Revised test to check and close all of the streams used in the pipeline.
>
> The test now checks the content length and closes each stdout and stderr
> stream.
>
> The previous technique to redirect stderr to stdout was ineffective because
On Wed, 17 Aug 2022 23:11:23 GMT, Joe Darcy wrote:
>> The use of lambda's in the initialization of AccessFlag runs afoul of CDS in
>> some cases due to occurring early in the platform's initialization. Instead
>> of lambdas, using anonymous classes gets around the issue.
>>
>> Clean tier1 and
On Wed, 17 Aug 2022 15:16:24 GMT, Paul Sandoz wrote:
> > > Much better to flip the operation and the receiver + first arg to the
> > > blend.
> >
> >
> > I'm not quite understand what the flip operation here mean. The current
> > code is simple enough to me. Could you please show more details
On Wed, 17 Aug 2022 23:11:23 GMT, Joe Darcy wrote:
>> The use of lambda's in the initialization of AccessFlag runs afoul of CDS in
>> some cases due to occurring early in the platform's initialization. Instead
>> of lambdas, using anonymous classes gets around the issue.
>>
>> Clean tier1 and
On Wed, 17 Aug 2022 22:53:55 GMT, Paul Sandoz wrote:
> Its a shame. Code changes look good. I recommend adding an internal comment
> within the top of the class declaration indicating why anon inner classes are
> used, esp. since this there is more action at a distance than the usual case
> wh
> The use of lambda's in the initialization of AccessFlag runs afoul of CDS in
> some cases due to occurring early in the platform's initialization. Instead
> of lambdas, using anonymous classes gets around the issue.
>
> Clean tier1 and tier 2 Mach 5 run with these changes.
Joe Darcy has updat
On Wed, 17 Aug 2022 22:33:03 GMT, Joe Darcy wrote:
> The use of lambda's in the initialization of AccessFlag runs afoul of CDS in
> some cases due to occurring early in the platform's initialization. Instead
> of lambdas, using anonymous classes gets around the issue.
>
> Clean tier1 and tier
On Wed, 17 Aug 2022 22:33:03 GMT, Joe Darcy wrote:
> The use of lambda's in the initialization of AccessFlag runs afoul of CDS in
> some cases due to occurring early in the platform's initialization. Instead
> of lambdas, using anonymous classes gets around the issue.
>
> Clean tier1 and tier
The use of lambda's in the initialization of AccessFlag runs afoul of CDS in
some cases due to occurring early in the platform's initialization. Instead of
lambdas, using anonymous classes gets around the issue.
Clean tier1 and tier 2 Mach 5 run with these changes.
-
Commit message
Hello,
when ForkJoinPool.getCommonPoolParallelism() is < 2, CompletableFuture uses a
ThreadPerTaskExecutor. As the name implies,
that executor creates a new thread per task.
My question is, why is it implemented this way?
This approach can cause drastic performance decreases for applications maki
Hello,
originally I reported this on the bug tracker, but was asked to first post this
topic to this mailing list. I was told that afterwards the bug report will be
created.
The internal method `java.lang.ConditionalSpecialCasing#lookUpTable` is used
for special case conversion rules, and is ca
On Wed, 17 Aug 2022 17:59:34 GMT, Brian Burkhalter wrote:
>> On Windows, suppress failure if the total space indicated by `df` is less
>> than `FileStore::getTotalSpace` and the free space indicated by `df` equals
>> `FileStore::getUnallocatedSpace`.
>
> Brian Burkhalter has updated the pull re
On Tue, 16 Aug 2022 15:06:50 GMT, Aleksey Shipilev wrote:
> I noticed that current VarHandle/Unsafe test cases do not test the
> always-failing cases. Strong CASes do test both always-success and
> always-failing scenarios, while weak CASes only test spurious-failure tests.
> We should be also
On Tue, 16 Aug 2022 15:06:50 GMT, Aleksey Shipilev wrote:
> I noticed that current VarHandle/Unsafe test cases do not test the
> always-failing cases. Strong CASes do test both always-success and
> always-failing scenarios, while weak CASes only test spurious-failure tests.
> We should be also
On Wed, 17 Aug 2022 17:35:39 GMT, Smita Kamath wrote:
>> 8289552: Make intrinsic conversions between bit representations of half
>> precision values and floats
>
> Smita Kamath has updated the pull request incrementally with one additional
> commit since the last revision:
>
> Added a jmh mi
> On Windows, suppress failure if the total space indicated by `df` is less
> than `FileStore::getTotalSpace` and the free space indicated by `df` equals
> `FileStore::getUnallocatedSpace`.
Brian Burkhalter has updated the pull request incrementally with one additional
commit since the last rev
On Fri, 12 Aug 2022 15:13:06 GMT, Brian Burkhalter wrote:
>> Brian Burkhalter has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> 8291911: Account for quotas on Windows.
>
> test/jdk/java/io/File/GetXSpace.java line 244:
>
>> 242:
On Fri, 5 Aug 2022 16:36:23 GMT, Smita Kamath wrote:
> 8289552: Make intrinsic conversions between bit representations of half
> precision values and floats
JMH results
Before patch
Benchmark (TESTSIZE) Mode Cnt
Score Error Units
Fp16Conv
> 8289552: Make intrinsic conversions between bit representations of half
> precision values and floats
Smita Kamath has updated the pull request incrementally with one additional
commit since the last revision:
Added a jmh microbenchmark
-
Changes:
- all: https://git.openjdk.
On Wed, 17 Aug 2022 15:32:49 GMT, Mahendra Chhipa wrote:
> Added tests for namespace Axis. Tests incluse namspace expressions, namespace
> node counts and namespace node scope.
Hi @JoeWang-Java , Could you please review this PR.
-
PR: https://git.openjdk.org/jdk/pull/9906
Added tests for namespace Axis. Tests incluse namspace expressions, namespace
node counts and namespace node scope.
-
Commit messages:
- JDK-8289510 : Improve test coverage for XPath Axes: namespace
Changes: https://git.openjdk.org/jdk/pull/9906/files
Webrev: https://webrevs.openj
Revised test to check and close all of the streams used in the pipeline.
The test now checks the content length and closes each stdout and stderr stream.
The previous technique to redirect stderr to stdout was ineffective because the
fd/stream was still created in the parent process. Created
[
On Wed, 17 Aug 2022 09:48:29 GMT, Xiaohong Gong wrote:
> > Much better to flip the operation and the receiver + first arg to the blend.
>
> I'm not quite understand what the flip operation here mean. The current code
> is simple enough to me. Could you please show more details? Thanks a lot!
I
On Wed, 3 Aug 2022 16:28:31 GMT, Eric Caspole wrote:
> These changes reduce the default run time from about 1 day 22 hours to about
> 6 hours with good stability we can use in weekly testing.
This pull request has now been integrated.
Changeset: 0fc92637
Author:Eric Caspole
URL:
ht
On Tue, 16 Aug 2022 14:35:14 GMT, Eric Caspole wrote:
>> These changes reduce the default run time from about 1 day 22 hours to about
>> 6 hours with good stability we can use in weekly testing.
>
> Eric Caspole has updated the pull request incrementally with one additional
> commit since the l
On Mon, 15 Aug 2022 11:16:06 GMT, Aleksey Shipilev wrote:
> The affected file was added by
> [JDK-8290059](https://bugs.openjdk.org/browse/JDK-8290059), and the code that
> fails the compilation is under `#ifdef _WIN32`, and it only (?) gets compiled
> for tests. Looks like we really need the
On Mon, 1 Aug 2022 11:46:52 GMT, Aleksey Shipilev wrote:
> See bug report for reproducer and error message. The warning looks quite
> superficial, and I initially suspected that it complains about `int len =
> (int)strlen(str)` cast of `size_t`. But what is confusing is nearly the
> similar co
On Mon, 15 Aug 2022 13:56:38 GMT, Aleksey Shipilev wrote:
>> See bug report for reproducer and error message. The warning looks quite
>> superficial, and I initially suspected that it complains about `int len =
>> (int)strlen(str)` cast of `size_t`. But what is confusing is nearly the
>> simil
On Tue, 16 Aug 2022 15:48:15 GMT, Aleksey Shipilev wrote:
>> We have a few reports that existing Weak* VarHandle tests are still flaky,
>> for example on large AArch64 machines or small RISC-V machines.
>>
>> The flakiness is intrinsic to the nature of Weak* operations under tests,
>> that can
On Wed, 17 Aug 2022 11:05:50 GMT, Aleksey Shipilev wrote:
> > I'm confused. How does adding EnsureCapacity in newString646_US fix the
> > compiler warning mentioned in JBS?
>
> I think this is a bona-fide compiler static analyzer bug. GCC 12 compiles
> this code fine. So, we have two options:
On Mon, 15 Aug 2022 13:56:38 GMT, Aleksey Shipilev wrote:
>> See bug report for reproducer and error message. The warning looks quite
>> superficial, and I initially suspected that it complains about `int len =
>> (int)strlen(str)` cast of `size_t`. But what is confusing is nearly the
>> simil
On Wed, 17 Aug 2022 08:55:58 GMT, Thomas Stuefe wrote:
> I'm confused. How does adding EnsureCapacity in newString646_US fix the
> compiler warning mentioned in JBS?
I think this is a bona-fide compiler static analyzer bug. GCC 12 compiles this
code fine. So, we have two options: a) disable th
On Mon, 15 Aug 2022 16:17:35 GMT, Paul Sandoz wrote:
> Looks good.
Thanks for looking at this patch @PaulSandoz !
> Much better to flip the operation and the receiver + first arg to the blend.
I'm not quite understand what the flip operation here mean. The current code is
simple enough to me
On Mon, 15 Aug 2022 17:43:27 GMT, Volker Simonis wrote:
> The problem is that after
> [JDK-8281962](https://bugs.openjdk.org/browse/JDK-8281962) we call `fill()`
> unconditionally (and before calling `Inflater::inflate()`) in
> `InflaterInputStream::read()` if `Inflater::needsInput()` is true.
On Tue, 16 Aug 2022 20:01:10 GMT, Lance Andersen wrote:
>> Volker Simonis has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Changed the payload to a more innocent version
>
> This looks OK Volker.
>
> It would be nice if possible to add a
On Mon, 15 Aug 2022 13:56:38 GMT, Aleksey Shipilev wrote:
>> See bug report for reproducer and error message. The warning looks quite
>> superficial, and I initially suspected that it complains about `int len =
>> (int)strlen(str)` cast of `size_t`. But what is confusing is nearly the
>> simil
On Mon, 15 Aug 2022 12:23:41 GMT, Ao Qi wrote:
> For example, java/lang/Thread/jni/AttachCurrentThread/AttachTest.java#id1
> failed on LoongArch64 (probably other platforms unsupported in
> src/java.base/share/classes/jdk/internal/foreign/CABI.java might have the
> same issue):
>
>
> Except
On Tue, 16 Aug 2022 15:06:50 GMT, Aleksey Shipilev wrote:
> I noticed that current VarHandle/Unsafe test cases do not test the
> always-failing cases. Strong CASes do test both always-success and
> always-failing scenarios, while weak CASes only test spurious-failure tests.
> We should be also
On Mon, 15 Aug 2022 13:56:38 GMT, Aleksey Shipilev wrote:
>> See bug report for reproducer and error message. The warning looks quite
>> superficial, and I initially suspected that it complains about `int len =
>> (int)strlen(str)` cast of `size_t`. But what is confusing is nearly the
>> simil
On Mon, 15 Aug 2022 11:16:06 GMT, Aleksey Shipilev wrote:
> The affected file was added by
> [JDK-8290059](https://bugs.openjdk.org/browse/JDK-8290059), and the code that
> fails the compilation is under `#ifdef _WIN32`, and it only (?) gets compiled
> for tests. Looks like we really need the
On Wed, 10 Aug 2022 09:18:01 GMT, Alan Bateman wrote:
> Change the test to use a custom scheduler so there is better control on when
> the carrier threads terminates. Also convert test to TestNG so that all test
> cases can be run in the context of a virtual thread.
This pull request has now b
> Change the test to use a custom scheduler so there is better control on when
> the carrier threads terminates. Also convert test to TestNG so that all test
> cases can be run in the context of a virtual thread.
Alan Bateman has updated the pull request with a new target base due to a merge
or
47 matches
Mail list logo
