On Fri, 9 May 2025 09:13:41 GMT, Leo Korinth wrote:
> > > My change of timeout factor to 0.7 is only temporal, as I said: it will
> > > be reverted to 4 before integration.
> >
> >
> > Is really worth reverting back to 4 instead of trying to get jtreg released
> > with CODETOOLS-7903961 and t
On Fri, 9 May 2025 08:40:44 GMT, Leo Korinth wrote:
> My change of timeout factor to 0.7 is only temporal, as I said: it will be
> reverted to 4 before integration.
Is really worth reverting back to 4 instead of trying to get jtreg released
with CODETOOLS-7903961 and then integrate this change
On Thu, 8 May 2025 14:51:24 GMT, Leo Korinth wrote:
> This change tries to add timeout to individual testcases so that I am able to
> run them with a timeout factor of 1 in the future (JDK-8260555).
>
> The first commit changes the timeout factor to 0.7, so that I can run tests
> and test the
On Sun, 16 Mar 2025 02:54:36 GMT, Ioi Lam wrote:
> This is probably not the right thing to do.
I agree that this doesn't sound like the right thing to do. This breaks the
jtreg -othervm mode.
I use the -othervm mode whenever I want to run reproduce a failure in jtreg. In
-othervm mode the pwd
On Mon, 20 Jan 2025 07:56:49 GMT, Axel Boldt-Christmas
wrote:
> The proposed change here is the following:
> 1. Move the `vmdependencies` list head from the `Context` to the `CallSite`
> object
> 2. Remove the Context object and its corresponding cleaner
>
> (1.) fixes the crash. (2.) is bec
On Thu, 17 Oct 2024 14:28:30 GMT, Patricio Chilano Mateo
wrote:
> This is the implementation of JEP 491: Synchronize Virtual Threads without
> Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for
> further details.
>
> In order to make the code review easier the changes hav
On Wed, 30 Oct 2024 23:14:53 GMT, Patricio Chilano Mateo
wrote:
>> This might confuse the change for JEP 450 since with CompactObjectHeaders
>> there's no klass_gap, so depending on which change goes first, there will be
>> conditional code here. Good question though, it looks like we only eve
On Wed, 30 Oct 2024 23:14:53 GMT, Patricio Chilano Mateo
wrote:
>> This might confuse the change for JEP 450 since with CompactObjectHeaders
>> there's no klass_gap, so depending on which change goes first, there will be
>> conditional code here. Good question though, it looks like we only eve
On Fri, 25 Oct 2024 08:25:21 GMT, Axel Boldt-Christmas
wrote:
>> This is the implementation task for `JEP 490: ZGC: Remove the
>> Non-Generational Mode`. See the JEP for details.
>> [JDK-8335850](https://bugs.openjdk.org/browse/JDK-8335850)
>
> Axel Boldt-Christmas has updated the pull request
On Thu, 24 Oct 2024 03:38:21 GMT, Patricio Chilano Mateo
wrote:
>> This is the implementation of JEP 491: Synchronize Virtual Threads without
>> Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for
>> further details.
>>
>> In order to make the code review easier the change
On Tue, 22 Oct 2024 15:32:45 GMT, Ioi Lam wrote:
>> My proposal was to use it in this file (iterator.inline.hpp) and not
>> iterator.hpp. I see no need to route this through the .cpp file.
>
> iterator.inline.hpp is included by many cpp file (580 out of 1409 .o files in
> hotspot), so I don't w
On Mon, 21 Oct 2024 20:31:59 GMT, Ioi Lam wrote:
>> src/hotspot/share/memory/iterator.inline.hpp line 57:
>>
>>> 55: ClaimMetadataVisitingOopIterateClosure::do_cld(cld);
>>> 56: } else {
>>> 57: assert_is_pending_aot_linked_class(k);
>>
>> Would there be a drawback to just adding
>>
On Fri, 18 Oct 2024 20:09:15 GMT, Ioi Lam wrote:
>> I filed [JDK-8342429](https://bugs.openjdk.org/browse/JDK-8342429) "Cache
>> classes in loaded state" to address this properly.
>
> I added an assert to limit the cases where the GCs can see null
> ClassLoaderData from a klass
> [3f09464](htt
On Fri, 18 Oct 2024 20:09:04 GMT, Ioi Lam wrote:
>> This is the 7th and final PR for [JEP 483: Ahead-of-Time Class Loading &
>> Linking](https://bugs.openjdk.org/browse/JDK-8315737).
>>
>> This PR implements the AOT-linking of invokedynamic callsites:
>> - We only link lambda expressions (`Lamb
On Fri, 18 Oct 2024 06:46:22 GMT, Axel Boldt-Christmas
wrote:
>> This is the implementation task for `JEP 490: ZGC: Remove the
>> Non-Generational Mode`. See the JEP for details.
>> [JDK-8335850](https://bugs.openjdk.org/browse/JDK-8335850)
>
> Axel Boldt-Christmas has updated the pull request
On Tue, 15 Oct 2024 05:21:53 GMT, Ioi Lam wrote:
>> This is the 7th and final PR for [JEP 483: Ahead-of-Time Class Loading &
>> Linking](https://bugs.openjdk.org/browse/JDK-8315737).
>>
>> This PR implements the AOT-linking of invokedynamic callsites:
>> - We only link lambda expressions (`Lamb
On Wed, 9 Oct 2024 12:57:36 GMT, Axel Boldt-Christmas
wrote:
>> This is the implementation task for `JEP 490: ZGC: Remove the
>> Non-Generational Mode`. See the JEP for details.
>> [JDK-8335850](https://bugs.openjdk.org/browse/JDK-8335850)
>
> Axel Boldt-Christmas has updated the pull request
On Wed, 9 Oct 2024 12:57:36 GMT, Axel Boldt-Christmas
wrote:
>> This is the implementation task for `JEP 490: ZGC: Remove the
>> Non-Generational Mode`. See the JEP for details.
>> [JDK-8335850](https://bugs.openjdk.org/browse/JDK-8335850)
>
> Axel Boldt-Christmas has updated the pull request
The `ClassLoadingMXBean` and `MemoryMXBean` APIs have `setVerbose` methods to
control verbose mode and `isVerbose` methods to query it. Some JCK tests expect
`setVerbose(false)` to disable verbose mode and, subsequently, `isVerbose()` to
return false. However, if logging to a file is enabled by
On Mon, 20 May 2024 07:24:16 GMT, Axel Boldt-Christmas
wrote:
>> Improve `java/util/zip/EntryCount64k.java` stderr parsing by ignoring
>> deprecated warnings. Testing non-generational ZGC requires the use of a
>> deprecated option.
>
> Axel Boldt-Christmas has updated the pull request incremen
On Mon, 20 May 2024 07:22:49 GMT, Axel Boldt-Christmas
wrote:
>> Improve ` java/util/logging/LoggingDeadlock2.java` stderr parsing by
>> ignoring deprecated warnings. Testing non-generational ZGC requires the use
>> of a deprecated option.
>
> Axel Boldt-Christmas has updated the pull request
On Wed, 13 Mar 2024 20:10:25 GMT, Roger Riggs wrote:
>> The intermittent failure of ObjectStreamClassCaching is due to an incorrect
>> assumption about GC behavior and a race condition.
>>
>> Removed test based on incorrect assumptions about simultaneous clearing of
>> WeakReferences.
>> Added
On Wed, 13 Mar 2024 19:41:25 GMT, Roger Riggs wrote:
>> The intermittent failure of ObjectStreamClassCaching is due to an incorrect
>> assumption about GC behavior and a race condition.
>>
>> Removed test based on incorrect assumptions about simultaneous clearing of
>> WeakReferences.
>> Added
we find
> this output to be too noisy.
Stefan Karlsson has updated the pull request incrementally with one additional
commit since the last revision:
Update copyright years
-
Changes:
- all: https://git.openjdk.org/jdk/pull/16807/files
- new: https://git.openjdk.org/jdk
On Fri, 12 Jan 2024 01:10:49 GMT, Leonid Mesnik wrote:
> Needed to update copyrights now.
Even when the code was written in 2023?
-
PR Comment: https://git.openjdk.org/jdk/pull/16807#issuecomment-1888699636
On Wed, 10 Jan 2024 12:09:07 GMT, Stefan Karlsson wrote:
> TestGCLockerWithShenandoah.java was recently removed, but the TEST.groups
> file still has a reference to it. This causes problems in our CI pipeline.
Thanks for the reviews!
-
PR Comment: https://git.openjdk.org/jd
On Wed, 10 Jan 2024 12:09:07 GMT, Stefan Karlsson wrote:
> TestGCLockerWithShenandoah.java was recently removed, but the TEST.groups
> file still has a reference to it. This causes problems in our CI pipeline.
This pull request has now been integrated.
Changeset: ec385057
Author:
TestGCLockerWithShenandoah.java was recently removed, but the TEST.groups file
still has a reference to it. This causes problems in our CI pipeline.
-
Commit messages:
- Revert unrelated changes
- 8323508: Remove TestGCLockerWithShenandoah.java line from TEST.groups
Changes: https
On Wed, 10 Jan 2024 12:09:07 GMT, Stefan Karlsson wrote:
> TestGCLockerWithShenandoah.java was recently removed, but the TEST.groups
> file still has a reference to it. This causes problems in our CI pipeline.
Thanks. The unrelated change has been reverted.
-
PR Comment:
On Fri, 5 Jan 2024 08:22:41 GMT, Stefan Karlsson wrote:
>> Most functions in ProcessTools are declared to throw Exceptions, or one of
>> its subclasses. However, there are a small number of functions that are
>> unnecessarily declared to throw Throwable instead of Exception.
On Wed, 3 Jan 2024 09:51:24 GMT, Stefan Karlsson wrote:
> Most functions in ProcessTools are declared to throw Exceptions, or one of
> its subclasses. However, there are a small number of functions that are
> unnecessarily declared to throw Throwable instead of Exception. I propose
we find
> this output to be too noisy.
Stefan Karlsson has updated the pull request with a new target base due to a
merge or a rebase. The pull request now contains three commits:
- Merge remote-tracking branch 'upstream/master' into
8320699_OutputAnalyzer_progress_logging
- Updat
ow Exception.
>
> This is a trivial patch to make it easier to refactor tests to use the
> updated functions.
>
> Tested manually, but will wait for GHA to verify that the change is OK.
Stefan Karlsson has updated the pull request incrementally with one additional
commit since the last
Most functions in ProcessTools are declared to throw Exceptions, or one of its
subclasses. However, there are a small number of functions that are
unnecessarily declared to throw Throwable instead of Exception. I propose that
we change them to also be declared to throw Exception.
This is a triv
On Mon, 11 Dec 2023 09:15:50 GMT, Stefan Karlsson wrote:
> [JDK-8315097](https://bugs.openjdk.org/browse/JDK-8315097): 'Rename
> createJavaProcessBuilder' changed the name of the ProcessTools helper
> functions used to create `ProcessBuilder`s used to spawn new java test
&
I propose that we name this functions using the same naming scheme we used
> for `createTestJavaProcessBuilder` and `createLimitedTestJavaProcessBuilder`.
> That is, we change `executeTestJvm` to `executeTestJava` and add a new
> `executeLimitedTestJava` function.
Stefan Karlsson has updated the pull reque
On Mon, 11 Dec 2023 11:16:05 GMT, Stefan Karlsson wrote:
> There is some logging printed when tests spawns processes. This logging is
> triggered from calls to `OutputAnalyzer`, when it delegates calls to
> `LazyOutputBuffer`.
>
> If we write code like this:
>
&
On Mon, 11 Dec 2023 14:06:43 GMT, Stefan Karlsson wrote:
>> [JDK-8315097](https://bugs.openjdk.org/browse/JDK-8315097): 'Rename
>> createJavaProcessBuilder' changed the name of the ProcessTools helper
>> functions used to create `ProcessBuilder`s used to spawn
I propose that we name this functions using the same naming scheme we used
> for `createTestJavaProcessBuilder` and `createLimitedTestJavaProcessBuilder`.
> That is, we change `executeTestJvm` to `executeTestJava` and add a new
> `executeLimitedTestJava` function.
Stefan Karlsson has updated the pull reque
On Tue, 12 Dec 2023 09:01:08 GMT, Stefan Karlsson wrote:
>> There is some logging printed when tests spawns processes. This logging is
>> triggered from calls to `OutputAnalyzer`, when it delegates calls to
>> `LazyOutputBuffer`.
>>
>> If we write code like
nished for process
> 2547719
>
> testExecuteProcessStdout
> [2023-12-11T11:05:44.049509860Z] Gathering output for process 2547741
> [2023-12-11T11:05:46.227768897Z] Waiting for completion for process 2547741
> [2023-12-11T11:05:46.228021173Z] Waiting for completion finished for pro
nished for process
> 2547719
>
> testExecuteProcessStdout
> [2023-12-11T11:05:44.049509860Z] Gathering output for process 2547741
> [2023-12-11T11:05:46.227768897Z] Waiting for completion for process 2547741
> [2023-12-11T11:05:46.228021173Z] Waiting for completion finished for proc
On Tue, 12 Dec 2023 07:43:31 GMT, David Holmes wrote:
>> Stefan Karlsson has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Typo
>
> test/lib/jdk/test/lib/process/OutputAnalyzer.java line 111:
>
>&g
On Mon, 11 Dec 2023 11:16:05 GMT, Stefan Karlsson wrote:
> There is some logging printed when tests spawns processes. This logging is
> triggered from calls to `OutputAnalyzer`, when it delegates calls to
> `LazyOutputBuffer`.
>
> If we write code like this:
>
&
I propose that we name this functions using the same naming scheme we used
> for `createTestJavaProcessBuilder` and `createLimitedTestJavaProcessBuilder`.
> That is, we change `executeTestJvm` to `executeTestJava` and add a new
> `executeLimitedTestJava` function.
Stefan Karlsson has updated the pull
I propose that we name this functions using the same naming scheme we used
> for `createTestJavaProcessBuilder` and `createLimitedTestJavaProcessBuilder`.
> That is, we change `executeTestJvm` to `executeTestJava` and add a new
> `executeLimitedTestJava` function.
Stefan Karlsson has updated the pull request i
There is some logging printed when tests spawns processes. This logging is
triggered from calls to `OutputAnalyzer`, when it delegates calls to
`LazyOutputBuffer`.
If we write code like this:
ProcessBuilder pb = ProcessTools.createTestJavaProcessBuilder(...);
OutputAnalyzer output = new OutputA
[JDK-8315097](https://bugs.openjdk.org/browse/JDK-8315097): 'Rename
createJavaProcessBuilder' changed the name of the ProcessTools helper functions
used to create `ProcessBuilder`s used to spawn new java test processes.
We now have `createTestJavaProcessBuilder` and `createLimitedTestJavaProcess
On Wed, 6 Dec 2023 01:56:46 GMT, David Holmes wrote:
> FWIW exitCode out numbers exitValue in source code 3:1 (and > 5:1 in test
> code).
That might be the case, but both the called function returning the value and
the function we are changing uses the name exitValue. It seems irrelevant that
On Fri, 1 Dec 2023 12:44:17 GMT, Jaikiran Pai wrote:
>> Can I please get a review for this change to the test library's
>> `OutputAnalyzer` class, which proposes to remove some unnecessary logging
>> from the `getExitValue()` call?
>>
>> As noted in https://bugs.openjdk.org/browse/JDK-8321163,
On Fri, 1 Dec 2023 11:14:04 GMT, Jaikiran Pai wrote:
>> test/lib/jdk/test/lib/process/OutputBuffer.java line 150:
>>
>>> 148: @Override
>>> 149: public int getExitValue() {
>>> 150: Integer exitCode = this.processExitCode;
>>
>> Do we really need the local `exitCode` variable? Eve
On Fri, 1 Dec 2023 11:09:30 GMT, Stefan Karlsson wrote:
>> Can I please get a review for this change to the test library's
>> `OutputAnalyzer` class, which proposes to remove some unnecessary logging
>> from the `getExitValue()` call?
>>
>> As noted in
On Fri, 1 Dec 2023 09:48:23 GMT, Jaikiran Pai wrote:
> Can I please get a review for this change to the test library's
> `OutputAnalyzer` class, which proposes to remove some unnecessary logging
> from the `getExitValue()` call?
>
> As noted in https://bugs.openjdk.org/browse/JDK-8321163, righ
On Thu, 30 Nov 2023 12:19:33 GMT, Jaikiran Pai wrote:
> Hello Stefan,
>
> > The test were I want to use this is a long-running stress test that is
> > known to be good at shaking out JVM hangs. It has been written to provide
> > its own output about spawned processes and what they are doing, a
we find
> this output to be too noisy.
Stefan Karlsson has updated the pull request incrementally with one additional
commit since the last revision:
Update OutputBuffer.java copyright years
-
Changes:
- all: https://git.openjdk.org/jdk/pull/16807/files
- new: https://
On Fri, 24 Nov 2023 17:01:29 GMT, Jaikiran Pai wrote:
> Hello Stefan, I agree with David that I have found these logs to be useful -
> it shows that process launched by the test hasn't yet finished and is being
> waited upon. The log message when written will have a timestamp and can then
> al
On Fri, 24 Nov 2023 17:13:30 GMT, Jaikiran Pai wrote:
> Other than a quick local test run, I haven't tested it for anything else. It
> did improve the situation in one of my test and it now only logs it once. In
> the setup that you are seeing this large amount of logging, would you be able
>
On Fri, 24 Nov 2023 13:06:05 GMT, David Holmes wrote:
> I can't help but feel that if you disable this output then you are going to
> be missing it in the cases that you need it! Something will go wrong and
> there won't be enough info in the log to know what it was.
My experience is that I wo
On Fri, 24 Nov 2023 10:34:02 GMT, Stefan Karlsson wrote:
> Tests using ProcessTools.executeProcess gets the following output written to
> stdout:
> [2023-11-24T09:58:16.797540608Z] Gathering output for process 2517117
> [2023-11-24T09:58:23.070781345Z] Waiting for completion for pro
Tests using ProcessTools.executeProcess gets the following output written to
stdout:
[2023-11-24T09:58:16.797540608Z] Gathering output for process 2517117
[2023-11-24T09:58:23.070781345Z] Waiting for completion for process 2517117
[2023-11-24T09:58:23.071045055Z] Waiting for completion finished fo
On Tue, 7 Nov 2023 10:36:00 GMT, Per Minborg wrote:
> This PR proposes to fix a compilation error in the TestLoadSegmentVarious
> class
Marked as reviewed by stefank (Reviewer).
-
PR Review: https://git.openjdk.org/jdk/pull/16537#pullrequestreview-1717370876
On Wed, 1 Nov 2023 00:06:35 GMT, Leonid Mesnik wrote:
> Test thread factory is a mode similar to VM flags and should not be used in
> ProcessTools.createLimitedTestJavaProcessBuilder(). Only
> createTestJavaProcessBuilder() should use it like jtreg VM options.
>
> Adding the test thread factor
On Tue, 5 Sep 2023 18:05:34 GMT, Roger Riggs wrote:
>> I have created an alternative that uses enums to force the user to make a
>> decision:
>> https://github.com/openjdk/jdk/compare/master...lkorinth:jdk:+process_tools
>> . Another alternative is to do the same but instead using an enum (I t
On Tue, 24 Oct 2023 07:49:30 GMT, Leo Korinth wrote:
>> Rename createJavaProcessBuilder so that it is not used by mistake instead of
>> createTestJvm.
>>
>> I have used the following sed script: `find -name "*.java" | xargs -n 1 sed
>> -i -e
>> "s/createJavaProcessBuilder(/createJavaProcessBu
On Wed, 30 Aug 2023 09:23:55 GMT, Leo Korinth wrote:
>> Rename createJavaProcessBuilder so that it is not used by mistake instead of
>> createTestJvm.
>>
>> I have used the following sed script: `find -name "*.java" | xargs -n 1 sed
>> -i -e
>> "s/createJavaProcessBuilder(/createJavaProcessBu
On Fri, 16 Jun 2023 11:41:14 GMT, Axel Boldt-Christmas
wrote:
>> The current implementation for testing generational ZGC with jtreg is
>> implemented with a filter on the mode flag `ZGenerational`. Because of this
>> only environments which set this flag explicitly will run most of the tests.
On Fri, 9 Jun 2023 10:07:31 GMT, Viktor Klang wrote:
>> The test used a too-small heap for generic testing, and coupled with looking
>> at `freeMemory()` it led to a less-than-ideal determinism of execution of
>> the test.
>
> Viktor Klang has updated the pull request incrementally with one add
On Fri, 9 Jun 2023 09:13:08 GMT, Viktor Klang wrote:
> The test used a too-small heap for generic testing, and coupled with looking
> at `freeMemory()` it led to a less-than-ideal determinism of execution of the
> test.
Did you test if this significantly changed the execution time of the test?
On Sun, 4 Jun 2023 11:28:33 GMT, Alan Bateman wrote:
> Thread.sleep has had quite a bit of churn recently to support virtual
> threads, add sleep(Duration), a JFR event, and the change the underlying
> implementation to support sub-millis precision. I think the changes have
> settled down now
On Tue, 16 May 2023 18:07:16 GMT, Leonid Mesnik wrote:
> Trivial fix that added missed useful command.
> Tested by running make of failure handler and verifying results.
Marked as reviewed by stefank (Reviewer).
-
PR Review: https://git.openjdk.org/jdk/pull/14018#pullrequestreview-
On Tue, 16 May 2023 18:07:16 GMT, Leonid Mesnik wrote:
> Trivial fix that added missed useful command.
> Tested by running make of failure handler and verifying results.
This looks good and "trivial". Thanks for fixing this.
-
PR Comment: https://git.openjdk.org/jdk/pull/14018#issu
On Wed, 10 May 2023 13:43:41 GMT, Martin Doerr wrote:
>> You are reasoning about implementation details. By using the provided
>> abstraction you and other maintainers (who might be unfamiliar with them)
>> would not have to do that. Also the assumptions you make introduce a hidden
>> dependen
72 matches
Mail list logo
