On Tue, 16 Aug 2022 08:23:11 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,
On Tue, 30 Aug 2022 14:18:11 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* operatio
On Mon, 22 Aug 2022 17:43:43 GMT, Paul Sandoz wrote:
>> Aleksey Shipilev has updated the pull request with a new target base due to
>> a merge or a rebase. The pull request now contains six commits:
>>
>> - Rework timeouts
>> - Merge branch 'master' i
On Mon, 29 Aug 2022 10:13:29 GMT, Aleksey Shipilev wrote:
> This is similar to
> [JDK-8245168](https://bugs.openjdk.org/browse/JDK-8245168), but the blanket
> change to allow all modules be compiled with default options is a net loss.
> Instead, we can hand-pick the major offe
On Mon, 29 Aug 2022 18:01:36 GMT, Aleksey Shipilev wrote:
>> This is similar to
>> [JDK-8245168](https://bugs.openjdk.org/browse/JDK-8245168), but the blanket
>> change to allow all modules be compiled with default options is a net loss.
>> Instead, we can hand-pick th
On Tue, 30 Aug 2022 14:18:11 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* operatio
xploding test time in worst cases.
Aleksey Shipilev has updated the pull request with a new target base due to a
merge or a rebase. The pull request now contains 12 commits:
- Rewind back to 100 attempts, 1ms delay
- Merge branch 'master' into JDK-8292407-varhandle-weak-resilien
On Mon, 29 Aug 2022 09:33:44 GMT, Сергей Цыпанов wrote:
>> Aleksey Shipilev has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Touchups
>
> src/java.base/share/classes/jdk/internal/module/ModuleHashes.java l
On Mon, 29 Aug 2022 09:18:16 GMT, Alan Bateman wrote:
> This issue will require discussion as it potentially impacts usage at
> run-time when the resolver runs at startup or when creating module layers.
Startup with/without CDS:
$ perf stat -r 100 build/linux-x86_64-server-release/images/jdk
Additional testing:
> - [x] Linux x86_64 fastdebug, `java/util/jar`
> - [x] Linux x86_64 fastdebug, `tools/jmod`
> - [x] Linux x86_64 fastdebug, `tools/jlink`
> - [x] Linux x86_64 fastdebug `tier1`
Aleksey Shipilev has updated the pull request incrementally with one additional
`jmod`/`jlink` are executed during build time to produce the `jmod` and the
base modules image. On slow hardware (Raspberry Pi -class, for example) and/or
slow VMs (debug, interpreter-only, for example) this takes a while. Profiling
shows the considerable time is spent on hashing modules either
On Fri, 26 Aug 2022 13:55:22 GMT, Aleksey Shipilev wrote:
> Look at implementation and figure out what happens if you do:
>
>
> computeHash("SHA-1") = someHash;
> computeHash("SHA-256") = ...?
>
>
> The caching method should actually check the al
On Fri, 26 Aug 2022 15:06:16 GMT, Aleksey Shipilev wrote:
>> Look at implementation and figure out what happens if you do:
>>
>>
>> computeHash("SHA-1") = someHash;
>> computeHash("SHA-256") = ...?
>>
>>
>> The caching me
On Fri, 26 Aug 2022 14:54:22 GMT, Alan Bateman wrote:
>> Aleksey Shipilev has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Review comments
>
> src/java.base/share/classes/jdk/internal/module/ModuleReference
nce only use SHA-256 today, but this is a landmine
> ready to fire.
>
> Additional testing:
> - [x] Linux x86_64 release, `java/lang/module` tests
Aleksey Shipilev has updated the pull request incrementally with one additional
commit since the last revision:
Comments
-
On Fri, 26 Aug 2022 14:33:33 GMT, Alan Bateman wrote:
> Can you make sure that you run all jar, jmod and jlink tests? Module hashes
> are generated at packaging time, then checked when generating the
> configuration in early startup.
`java/util/jar`, `jdk/tools/jmod`, `jdk/tools/jlink` -- all
On Fri, 26 Aug 2022 14:06:21 GMT, Alan Bateman wrote:
>> Aleksey Shipilev has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Review comments
>
> src/java.base/share/classes/jdk/internal/module/ModuleReference
On Fri, 26 Aug 2022 14:14:12 GMT, Alan Bateman wrote:
>> Aleksey Shipilev has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Touchups
>
> src/java.base/share/classes/jdk/internal/module/ModuleReference
nce only use SHA-256 today, but this is a landmine
> ready to fire.
>
> Additional testing:
> - [x] Linux x86_64 release, `java/lang/module` tests
Aleksey Shipilev has updated the pull request incrementally with one additional
commit since the last revision:
Review comments
-
On Fri, 26 Aug 2022 14:06:30 GMT, Alan Bateman wrote:
>> Aleksey Shipilev has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Touchups
>
> src/java.base/share/classes/jdk/internal/module/ModuleReferenceIm
nce only use SHA-256 today, but this is a landmine
> ready to fire.
>
> Additional testing:
> - [x] Linux x86_64 release, `java/lang/module` tests
Aleksey Shipilev has updated the pull request incrementally with one additional
commit since the last revision:
Touchups
-
Look at implementation and figure out what happens if you do:
computeHash("SHA-1") = someHash;
computeHash("SHA-256") = ...?
The caching method should actually check the algorithms match.
Does not seem to be a problem at this point, since we seem to be only calling
that methods with "SHA-25
xploding test time in worst cases.
Aleksey Shipilev has updated the pull request with a new target base due to a
merge or a rebase. The pull request now contains 10 commits:
- Merge branch 'master' into JDK-8292407-varhandle-weak-resilient
- Pull Handles.get out of the weak retry
On Wed, 24 Aug 2022 18:15:17 GMT, Aleksey Shipilev wrote:
> [JDK-8026344](https://bugs.openjdk.org/browse/JDK-8026344) added tests that
> subtly contradict the contract for `{Double,Long}Accumulator`-s, which breaks
> the tests on some platforms even in the single-threaded case.
>
On Wed, 24 Aug 2022 18:15:17 GMT, Aleksey Shipilev wrote:
> [JDK-8026344](https://bugs.openjdk.org/browse/JDK-8026344) added tests that
> subtly contradict the contract for `{Double,Long}Accumulator`-s, which breaks
> the tests on some platforms even in the single-threaded case.
>
[JDK-8026344](https://bugs.openjdk.org/browse/JDK-8026344) added tests that
subtly contradict the contract for `{Double,Long}Accumulator`-s, which breaks
the tests on some platforms even in the single-threaded case.
They use accumulators with binary plus as update function and using non-zero
va
xploding test time in worst cases.
Aleksey Shipilev has updated the pull request with a new target base due to a
merge or a rebase. The pull request now contains ten commits:
- Pull Handles.get out of the weak retry loop
- Drop weakDelay to 1
- Merge branch 'master' into JDK-8292407-
On Fri, 19 Aug 2022 18:14:16 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* operatio
On Mon, 22 Aug 2022 18:03:21 GMT, Daniel D. Daugherty
wrote:
>> Split the java/util/stream/SpinedBufferTest.java test into two parts:
>> - java/util/stream/SpinedBufferTest1.java has the first 6 test cases
>> - java/util/stream/SpinedBufferTes2.java has the second 6 test cases
>>
>> I couldn't
On Mon, 22 Aug 2022 16:49:34 GMT, Martin Doerr wrote:
> My concern is that we may not notice implementation problems any more when
> retrying so often. Accidental cache line sharing should better get fixed in
> the tests if possible. Context switching or cache capacity limits may cause 1
> fai
On Mon, 22 Aug 2022 13:12:25 GMT, Martin Doerr wrote:
> In general, I appreciate making these tests more resilient. However, I wonder
> about such large numbers for retry attempts. Smells like more than just
> sporadic failures. Are we sure there is no bug which causes more failures?
> Does it
On Fri, 19 Aug 2022 18:14:16 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* operatio
On Fri, 19 Aug 2022 18:14:16 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* operatio
On Sat, 20 Aug 2022 02:41:50 GMT, Daniel D. Daugherty
wrote:
>> Split the java/util/stream/SpinedBufferTest.java test into two parts:
>> - java/util/stream/SpinedBufferTest1.java has the first 6 test cases
>> - java/util/stream/SpinedBufferTes2.java has the second 6 test cases
>>
>> I couldn't
xploding test time in worst cases.
Aleksey Shipilev has updated the pull request with a new target base due to a
merge or a rebase. The pull request now contains six commits:
- Rework timeouts
- Merge branch 'master' into JDK-8292407-varhandle-weak-resilient
- Merge branch 'm
On Thu, 11 Aug 2022 20:09:06 GMT, Daniel D. Daugherty
wrote:
> Split the java/util/stream/SpinedBufferTest.java test into two parts:
> - java/util/stream/SpinedBufferTest1.java has the first 6 test cases
> - java/util/stream/SpinedBufferTes2.java has the second 6 test cases
>
> I couldn't figur
xploding test time in worst cases.
Aleksey Shipilev has updated the pull request with a new target base due to a
merge or a rebase. The pull request now contains four commits:
- Merge branch 'master' into JDK-8292407-varhandle-weak-resilient
- Update copyrights
- Also do Unsafe
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.
>
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.
>
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 rea
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
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 confu
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 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.
>
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 confu
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 rea
xploding test time in worst cases.
Aleksey Shipilev has updated the pull request incrementally with two additional
commits since the last revision:
- Update copyrights
- Also do Unsafe tests
-
Changes:
- all: https://git.openjdk.org/jdk/pull/9889/files
- new: https://gi
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 testing always-failing cases for these. Weak CAS can spuriously
fa
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-8155739](https://
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 "WINAPI" macro in the definition, so
that we match the stdcall. See
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 rea
On Mon, 15 Aug 2022 13:21:49 GMT, Alan Bateman wrote:
>> Aleksey Shipilev has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Init buf in newStringCp1252
>
> src/java.base/share/native/libjava/jni_util.c
implementation to dodge
> it.
>
> Additional testing:
> - [x] Linux x86_32 build with GCC 11
> - [x] Linux x86_32 `tier1` test with GCC 9
> - [x] Linux x86_64 `tier1` test with GCC 9
Aleksey Shipilev has updated the pull request with a new target base due to a
merge or a r
On Mon, 1 Aug 2022 14:50:48 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 confu
On Wed, 3 Aug 2022 22:17:38 GMT, Peter Levart wrote:
>> This is a continuation of effort from
>> https://github.com/openjdk/jdk/pull/9533 to fix the ObjectStreamClassCaching
>> test which is failing with various GCs != G1. The test class contains 2 test
>> methods:
>> - test2CacheReleaseUnderM
On Wed, 3 Aug 2022 06:24:16 GMT, Peter Levart wrote:
>> This is a continuation of effort from
>> https://github.com/openjdk/jdk/pull/9533 to fix the ObjectStreamClassCaching
>> test which is failing with various GCs != G1. The test class contains 2 test
>> methods:
>> - test2CacheReleaseUnderM
implementation to dodge
> it.
>
> Additional testing:
> - [x] Linux x86_32 build with GCC 11
> - [x] Linux x86_32 `tier1` test with GCC 9
> - [ ] Linux x86_64 `tier1` test with GCC 9
Aleksey Shipilev has updated the pull request incrementally with one additional
comm
On Tue, 19 Jul 2022 12:52:11 GMT, Aleksey Shipilev wrote:
> Some of the newly added Loom tests are long-running, and thus they delay the
> completion of otherwise very parallel tier1/jdk_loom. We can parallelize them
> a bit better to avoid these testing stalls.
>
> Improv
On Mon, 1 Aug 2022 08:37:11 GMT, Aleksey Shipilev wrote:
>> Some of the newly added Loom tests are long-running, and thus they delay the
>> completion of otherwise very parallel tier1/jdk_loom. We can parallelize
>> them a bit better to avoid these testing stalls.
>>
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
code in `newStringCp1252` apparently does not produce the warning:
On Mon, 1 Aug 2022 07:43:57 GMT, Alan Bateman wrote:
> No objection to changing these tests.
Did the changes in new commit.
-
PR: https://git.openjdk.org/jdk/pull/9554
tdebug after
> real 4m9.249s; -26%
> user 67m21.940s
> sys 1m57.625s
Aleksey Shipilev has updated the pull request with a new target base due to a
merge or a rebase. The incremental webrev excludes the unrelated changes
brought in by the merge/rebase. The pull request contains four
On Tue, 19 Jul 2022 12:52:11 GMT, Aleksey Shipilev wrote:
> Some of the newly added Loom tests are long-running, and thus they delay the
> completion of otherwise very parallel tier1/jdk_loom. We can parallelize them
> a bit better to avoid these testing stalls.
>
> Improv
On Mon, 18 Jul 2022 07:40:53 GMT, Aleksey Shipilev wrote:
> Test appears to pass fine with G1. But it fails with other GCs, for example
> Parallel, Shenandoah, etc, it fails:
>
>
> $ CONF=linux-x86_64-server-fastdebug make test
> TEST=java/io/ObjectStreamClass/ObjectStrea
On Mon, 18 Jul 2022 07:40:53 GMT, Aleksey Shipilev wrote:
> Test appears to pass fine with G1. But it fails with other GCs, for example
> Parallel, Shenandoah, etc, it fails:
>
>
> $ CONF=linux-x86_64-server-fastdebug make test
> TEST=java/io/ObjectStreamClass/ObjectStrea
On Wed, 27 Jul 2022 12:30:43 GMT, Aleksey Shipilev wrote:
>>> ...I can take this over, unless you want to do it, Aleksey?
>>
>> I find it dubious to try and guess what GCs would do with non-strong refs,
>> but feel free. Don't reassign the bug yet, just see how
On Mon, 25 Jul 2022 16:41:04 GMT, Aleksey Shipilev wrote:
> > ...I can take this over, unless you want to do it, Aleksey?
>
> I find it dubious to try and guess what GCs would do with non-strong refs,
> but feel free. Don't reassign the bug yet, just see how messy that wou
On Tue, 26 Jul 2022 10:16:31 GMT, Jaikiran Pai wrote:
>> test/jdk/java/nio/channels/vthread/BlockingChannelOps.java line 36:
>>
>>> 34: * @test id=useDirectRegister
>>> 35: * @bug 8284161
>>> 36: * @summary Basic tests of virtual threads doing blocking I/O with NIO
>>> channels
>>
>> Hello
On Tue, 19 Jul 2022 12:52:11 GMT, Aleksey Shipilev wrote:
> Some of the newly added Loom tests are long-running, and thus they delay the
> completion of otherwise very parallel tier1/jdk_loom. We can parallelize them
> a bit better to avoid these testing stalls.
>
> Improv
On Mon, 25 Jul 2022 14:51:32 GMT, Peter Levart wrote:
> ...I can take this over, unless you want to do it, Aleksey?
I find it dubious to try and guess what GCs would do with non-strong refs, but
feel free. Don't reassign the bug yet, just see how messy that would be?
-
PR: https:/
On Mon, 25 Jul 2022 13:04:46 GMT, Peter Levart wrote:
> Just a note that the failing test is not about checking that cache is cleared
> after plain System.gc(), but about checking that cache is NOT cleared after
> System.gc() when there was no real memory pressure. The cache uses
> SoftReferen
On Mon, 18 Jul 2022 07:40:53 GMT, Aleksey Shipilev wrote:
> Test appears to pass fine with G1. But it fails with other GCs, for example
> Parallel, Shenandoah, etc, it fails:
>
>
> $ CONF=linux-x86_64-server-fastdebug make test
> TEST=java/io/ObjectStreamClass/ObjectStrea
On Fri, 22 Jul 2022 10:46:57 GMT, Roman Kennke wrote:
> TBH, not certain how GC policies play into that, and how well WB is supported
> in each GC. Might be worth trying?
> Other that that, how does removinch System.gc() help make the test more
> reliable?
When you call `System.gc()` on some c
On Fri, 22 Jul 2022 10:36:32 GMT, Roman Kennke wrote:
> WhiteBox has a number of methods that allow better control over GC, e.g.
> fullGC(), concurrentGCRunToIdle(), etc. Would that help?
I think the test relies on assumption that `System.gc()` does the weak
reference clearing. Which is not gi
On Tue, 19 Jul 2022 12:52:11 GMT, Aleksey Shipilev wrote:
> Some of the newly added Loom tests are long-running, and thus they delay the
> completion of otherwise very parallel tier1/jdk_loom. We can parallelize them
> a bit better to avoid these testing stalls.
>
> Improv
On Mon, 18 Jul 2022 07:40:53 GMT, Aleksey Shipilev wrote:
> Test appears to pass fine with G1. But it fails with other GCs, for example
> Parallel, Shenandoah, etc, it fails:
>
>
> $ CONF=linux-x86_64-server-fastdebug make test
> TEST=java/io/ObjectStreamClass/ObjectStrea
Some of the newly added Loom tests are long-running, and thus they delay the
completion of otherwise very parallel tier1/jdk_loom. We can parallelize them a
bit better to avoid these testing stalls.
Improvements on Linux x86_64, TR 3970X, `jdk_loom hotspot_loom`:
# release before
real 4m41.42
On Mon, 18 Jul 2022 14:48:42 GMT, Roger Riggs wrote:
> Committing to the mainline and then requesting a backport of the changeset
> works too.
Yes, that would be my plan.
-
PR: https://git.openjdk.org/jdk19/pull/27
Test appears to pass fine with G1. But it fails with other GCs, for example
Parallel, Shenandoah, etc, it fails:
$ CONF=linux-x86_64-server-fastdebug make test
TEST=java/io/ObjectStreamClass/ObjectStreamClassCaching.java
TEST_VM_OPTS="-XX:+UseParallelGC"
test ObjectStreamClassCaching.testCach
On Thu, 16 Jun 2022 08:08:15 GMT, Aleksey Shipilev wrote:
> Test appears to pass fine with G1. But it fails with other GCs, for example
> Parallel, Shenandoah, etc, it fails:
>
>
> $ CONF=linux-x86_64-server-fastdebug make test
> TEST=java/io/ObjectStreamClass/ObjectStrea
On Thu, 16 Jun 2022 08:08:15 GMT, Aleksey Shipilev wrote:
> Test appears to pass fine with G1. But it fails with other GCs, for example
> Parallel, Shenandoah, etc, it fails:
>
>
> $ CONF=linux-x86_64-server-fastdebug make test
> TEST=java/io/ObjectStreamClass/ObjectStrea
Test appears to pass fine with G1. But it fails with other GCs, for example
Parallel, Shenandoah, etc, it fails:
$ CONF=linux-x86_64-server-fastdebug make test
TEST=java/io/ObjectStreamClass/ObjectStreamClassCaching.java
TEST_VM_OPTS="-XX:+UseParallelGC"
test ObjectStreamClassCaching.testCach
401 - 482 of 482 matches
Mail list logo
