On Fri, 24 May 2024 12:16:25 GMT, Ludvig Janiuk wrote:
> Adding commetns to clarify that the failure_handler selftests are intended to
> be run manually. Ideally this would include a more thorough description of
> the exepcted outputs, but this is what I have time to add right now.
Marked as r
On Fri, 24 May 2024 14:34:39 GMT, Ludvig Janiuk wrote:
> Also log the directory in which the command used by failure_handler was
> executed. While often the same, it isn't always, and so it this should
> simplify troubleshooting for someone looking at this at a glance without
> being a failure
The message is generated if cores (or any other tools) section doesn't exist or
is empty. However, there is no any tool for cores processing now defined. So
ERROR message is generating, confusing users.
The fix is to don't print error for empty toolset which is the valid case. The
message is sti
On Fri, 24 Feb 2023 22:15:18 GMT, Leonid Mesnik wrote:
> The solution proposed by Stefan K
>
> The startProcess() might wait forever for the expected line if the process
> exits (failed to start). It makes sense to just fail earlier in such cases.
>
> The fix also mo
On Thu, 30 May 2024 02:28:56 GMT, Leonid Mesnik wrote:
> The message is generated if cores (or any other tools) section doesn't exist
> or is empty. However, there is no any tool for cores processing now defined.
> So ERROR message is generating, confusing users.
> The fix
On Mon, 24 Jun 2024 16:16:29 GMT, SendaoYan wrote:
> Hi all,
> After [JDK-8294960](https://bugs.openjdk.org/browse/JDK-8294960), the
> footprint memory usage increased significantly when run the testcase with
> -Xcomp jvm options, then cause the testcase was killed by docker by OOM.
> Maybe
On Thu, 22 Sep 2022 09:16:28 GMT, Serguei Spitsyn wrote:
>> There are several places in VirtualThread class implementation where virtual
>> threads are being mounted or unmounted, so there is a transition of the
>> JavaThread identity from carrier thread to virtual thread and back. The
>> exec
The fix is contributed by @plummercj actually.
-
Commit messages:
- fix
Changes: https://git.openjdk.org/jdk/pull/10730/files
Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10730&range=00
Issue: https://bugs.openjdk.org/browse/JDK-8284614
Stats: 2 lines in 1 file changed: 0 i
On Wed, 23 Nov 2022 00:24:28 GMT, Serguei Spitsyn wrote:
> This problem has two sides.
> One is that the `VirtualThread::run() `cashes the field `notifyJvmtiEvents`
> value.
> It caused the native method `notifyJvmtiUnmountBegin()` not called after the
> field `notifyJvmtiEvents`
> value has be
On Wed, 23 Nov 2022 00:24:28 GMT, Serguei Spitsyn wrote:
> This problem has two sides.
> One is that the `VirtualThread::run() `cashes the field `notifyJvmtiEvents`
> value.
> It caused the native method `notifyJvmtiUnmountBegin()` not called after the
> field `notifyJvmtiEvents`
> value has be
On Wed, 23 Nov 2022 10:14:23 GMT, Serguei Spitsyn wrote:
>> This problem has two sides.
>> One is that the `VirtualThread::run() `cashes the field `notifyJvmtiEvents`
>> value.
>> It caused the native method `notifyJvmtiUnmountBegin()` not called after the
>> field `notifyJvmtiEvents`
>> value
On Wed, 22 Feb 2023 17:43:23 GMT, Evgeny Nikitin wrote:
>> Please review a set of improvements that should improve working with other
>> fuzzing generators and usage of JitTesterDriver with tests generated not by
>> the JITTester:
>>
>> - Provide better separation of individual test generation
The solution proposed by Stefan K
The startProcess() might wait forever for the expected line if the process
exits (failed to start). It makes sense to just fail earlier in such cases.
The fix also move
'output = new OutputAnalyzer(this.process);'
in method xrun() to be able to try to print them
On Fri, 24 Feb 2023 22:41:34 GMT, Roger Riggs wrote:
>> Leonid Mesnik has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> updated to always check if process is alive.
>
> test/lib/jdk/test/lib/process/Process
gt; in method xrun() to be able to try to print them in waitFor is
> failed/interrupted.
Leonid Mesnik has updated the pull request incrementally with one additional
commit since the last revision:
updated to always check if process is alive.
-
Changes:
- all: https://git.ope
gt; in method xrun() to be able to try to print them in waitFor is
> failed/interrupted.
Leonid Mesnik has updated the pull request incrementally with one additional
commit since the last revision:
fixed conditions.
-
Changes:
- all: https://git.openjdk.org/jdk/pull/12751/f
On Mon, 27 Feb 2023 04:54:57 GMT, David Holmes wrote:
>> Leonid Mesnik has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> updated to always check if process is alive.
>
> test/lib/jdk/test/lib/process/Process
gt; in method xrun() to be able to try to print them in waitFor is
> failed/interrupted.
Leonid Mesnik has updated the pull request incrementally with one additional
commit since the last revision:
added some extra time to dead process.
-
Changes:
- all: https://git.ope
gt; in method xrun() to be able to try to print them in waitFor is
> failed/interrupted.
Leonid Mesnik has updated the pull request incrementally with two additional
commits since the last revision:
- latch != updated
- message improved
-
Changes:
- all: https://git.ope
On Mon, 27 Feb 2023 22:48:46 GMT, David Holmes wrote:
>> Leonid Mesnik has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> added some extra time to dead process.
>
> test/lib/jdk/test/lib/process/Process
On Tue, 28 Feb 2023 02:42:33 GMT, David Holmes wrote:
>> Leonid Mesnik has updated the pull request incrementally with two additional
>> commits since the last revision:
>>
>> - latch != updated
>> - message improved
>
> This seems okay to me now. Thank
On Fri, 24 Feb 2023 22:15:18 GMT, Leonid Mesnik wrote:
> The solution proposed by Stefan K
>
> The startProcess() might wait forever for the expected line if the process
> exits (failed to start). It makes sense to just fail earlier in such cases.
>
> The fix also mo
It is the 2nd attempt to fix
[JDK-8303133](https://bugs.openjdk.org/browse/JDK-8303133) Update
ProcessTools.startProcess(...) to exit early if the process exit before
linePredicate is printed.
The first fix failed because it runs
Utils.waitForCondition(BooleanSupplier condition, long timeout, lo
On Wed, 1 Mar 2023 20:50:38 GMT, Leonid Mesnik wrote:
> It is the 2nd attempt to fix
> [JDK-8303133](https://bugs.openjdk.org/browse/JDK-8303133) Update
> ProcessTools.startProcess(...) to exit early if the process exit before
> linePredicate is printed.
>
> The first fix
On Wed, 15 Mar 2023 05:41:33 GMT, Leonid Mesnik wrote:
> The StreamPumper is fixed to process the last line even it is not finishes
> with '\n' or '\r'. The test included. Testing with tier1-3 also to verify
> that tests are not broken.
The ByteArrayOutputStream
The StreamPumper is fixed to process the last line even it is not finishes with
'\n' or '\r'. The test included. Testing with tier1-3 also to verify that tests
are not broken.
-
Commit messages:
- fix
- 8303697
Changes: https://git.openjdk.org/jdk/pull/13034/files
Webrev: https:
> The StreamPumper is fixed to process the last line even it is not finishes
> with '\n' or '\r'. The test included. Testing with tier1-3 also to verify
> that tests are not broken.
Leonid Mesnik has updated the pull request incrementally with one additional
c
On Wed, 15 Mar 2023 14:23:06 GMT, Leonid Mesnik wrote:
>> The StreamPumper is fixed to process the last line even it is not finishes
>> with '\n' or '\r'. The test included. Testing with tier1-3 also to verify
>> that tests are not broken.
>
>
> The StreamPumper is fixed to process the last line even it is not finishes
> with '\n' or '\r'. The test included. Testing with tier1-3 also to verify
> that tests are not broken.
Leonid Mesnik has updated the pull request incrementally with one additional
c
Hi
I’ve sent fix out for review: https://github.com/openjdk/jdk/pull/13058
Leonid
From: Tobias Hartmann
Date: Thursday, March 16, 2023 at 12:20 AM
To: Kosta Stojiljkovic , core-libs-dev@openjdk.org
Cc: Leonid Mesnik
Subject: Re: jtreg test test/jdk/java/lang/StackWalker/StackWalkTest.java
The test depends on the jtreg stack and should be updated.
The fix is backported from loom repo where jtreg with CODETOOLS-7903373 is used.
Tested with current promoted jtreg (without CODETOOLS-7903373) by running test.
-
Commit messages:
- 8304314: StackWalkTest.java fails after COD
> The StreamPumper is fixed to process the last line even it is not finishes
> with '\n' or '\r'. The test included. Testing with tier1-3 also to verify
> that tests are not broken.
Leonid Mesnik has updated the pull request incrementally with one additional
c
On Thu, 16 Mar 2023 06:19:14 GMT, Thomas Stuefe wrote:
>> Leonid Mesnik has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> comments added
>
> That also affects OutputAnalyzer, right? Does this affect parsi
> The StreamPumper is fixed to process the last line even it is not finishes
> with '\n' or '\r'. The test included. Testing with tier1-3 also to verify
> that tests are not broken.
Leonid Mesnik has updated the pull request incrementally with one additional
c
On Thu, 16 Mar 2023 13:26:35 GMT, Leonid Mesnik wrote:
> The test depends on the jtreg stack and should be updated.
> The fix is backported from loom repo where jtreg with CODETOOLS-7903373 is
> used.
> Tested with current promoted jtreg (without CODETOOLS-7903373) by running
&
On Wed, 15 Mar 2023 05:41:33 GMT, Leonid Mesnik wrote:
> The StreamPumper is fixed to process the last line even it is not finishes
> with '\n' or '\r'. The test included. Testing with tier1-3 also to verify
> that tests are not broken.
This pull request has no
On Fri, 17 Mar 2023 10:31:46 GMT, Serguei Spitsyn wrote:
>> This is needed for future performance/scalability improvements in JVMTI
>> support of virtual threads.
>> The update includes the following:
>>
>> 1. Refactored the `VirtualThread` native methods:
>> `notifyJvmtiMountBegin` and
On Sat, 18 Mar 2023 19:14:09 GMT, Mandy Chung wrote:
>> `ModuleInfoWriter` is not used by the runtime. Move it to the test library
>> as `jdk.test.lib.util.ModuleInfoWriter`. The tests are updated to use the
>> test library instead. `ModuleInfoWriter` depends on `jdk.internal.module`
>>
On Tue, 28 Mar 2023 19:36:18 GMT, Alan Bateman wrote:
>> JEP 444 proposes to make virtual threads a permanent feature in Java 21. The
>> APIs that were preview APIs in Java 19/20 are changed to permanent and their
>> `@since`/equivalent are changed to 21 (as per the guidance in JEP 12). The
>>
On Wed, 29 Mar 2023 00:08:21 GMT, Pavel Rappo wrote:
>> src/java.base/share/classes/java/lang/System.java line 2566:
>>
>>> 2564:
>>> 2565: public V executeOnCarrierThread(Callable task)
>>> throws Exception {
>>> 2566: if (Thread.currentThread() instanceof Virtual
On Wed, 29 Mar 2023 08:00:36 GMT, Alan Bateman wrote:
>> JEP 444 proposes to make virtual threads a permanent feature in Java 21. The
>> APIs that were preview APIs in Java 19/20 are changed to permanent and their
>> `@since`/equivalent are changed to 21 (as per the guidance in JEP 12). The
>>
Test TraceVirtualThreadLocals verifies that thread locals are dumped for
virtual threads. It fails when continuations are not available and virtual
threads are emulated.
The test failed on linux-x86 so I just want to mark it to have green github
actions results.
-
Commit messages:
On Tue, 11 Apr 2023 23:38:23 GMT, Leonid Mesnik wrote:
> Test TraceVirtualThreadLocals verifies that thread locals are dumped for
> virtual threads. It fails when continuations are not available and virtual
> threads are emulated.
>
> The test failed on linux-x86 so I just wan
On Tue, 11 Apr 2023 23:38:23 GMT, Leonid Mesnik wrote:
> Test TraceVirtualThreadLocals verifies that thread locals are dumped for
> virtual threads. It fails when continuations are not available and virtual
> threads are emulated.
>
> The test failed on linux-x86 so I just wan
On Mon, 17 Apr 2023 14:56:16 GMT, Christian Stein wrote:
> Please review the change to update to using jtreg 7.2.
>
> The primary change is to the `jib-profiles.js` file, which specifies the
> version of jtreg to use, for those systems that rely on this file. In
> addition, the requiredVersion
ProcessTools.startProcess() creates process and read it's output error streams.
So the any other using of corresponding Process.getInputStream() and
Process.getErrorStream() doesn't get process streams.
This fix preserve process streams content and allow to read it after process
completion. The
to read it after process
> completion. The another possible solution would be to throw exception when
> user tries to read already drained streams to fail tests earlier. However it
> complicates usage of ProcessTools.startProcess() methods.
>
> The regression test has been provided wi
On Thu, 20 Apr 2023 22:22:06 GMT, Chris Plummer wrote:
>> Leonid Mesnik has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> JStackStressTest.java updated.
>
> test/jdk/sun/tools/jhsdb/JStackStr
On Thu, 20 Apr 2023 22:54:49 GMT, David Holmes wrote:
>> test/lib/jdk/test/lib/process/ProcessTools.java line 750:
>>
>>> 748: public InputStream getInputStream() {
>>> 749: try {
>>> 750: waitFor();
>>
>> With this added `waitFor()` the assumption now is tha
On Thu, 20 Apr 2023 16:09:29 GMT, Leonid Mesnik wrote:
> ProcessTools.startProcess() creates process and read it's output error
> streams. So the any other using of corresponding Process.getInputStream() and
> Process.getErrorStream() doesn't get process streams.
>
>
ProcessTools.startProcess() creates process and read it's output error streams.
So the any other using of corresponding Process.getInputStream() and
Process.getErrorStream() doesn't get process streams.
This fix preserve process streams content and allow to read reuse the date. The
ByteArrayOut
On Mon, 24 Apr 2023 20:57:31 GMT, Chris Plummer wrote:
>> ProcessTools.startProcess() creates process and read it's output error
>> streams. So the any other using of corresponding Process.getInputStream()
>> and Process.getErrorStream() doesn't get process streams.
>>
>> This fix preserve pro
On Tue, 25 Apr 2023 03:06:09 GMT, Serguei Spitsyn wrote:
>> ProcessTools.startProcess() creates process and read it's output error
>> streams. So the any other using of corresponding Process.getInputStream()
>> and Process.getErrorStream() doesn't get process streams.
>>
>> This fix preserve p
stake
> instead of updating it.
>
> I run all tests to ensure that no failures are introduced.
Leonid Mesnik has updated the pull request incrementally with two additional
commits since the last revision:
- fixed
- renamed out to stdOut
-
Changes:
- all: https:/
On Wed, 26 Apr 2023 09:38:45 GMT, Serguei Spitsyn wrote:
>> Right. From the API caller's POV, it is asking for InputStreams that it can
>> use to read the process' stdout or stderr streams.
>
> Okay, thanks.
> I'm thinking about simple/short comments on this to make it clear this naming
> misma
On Fri, 21 Apr 2023 21:43:39 GMT, Leonid Mesnik wrote:
> ProcessTools.startProcess() creates process and read it's output error
> streams. So the any other using of corresponding Process.getInputStream() and
> Process.getErrorStream() doesn't get process streams.
>
>
The ProcessTools.startProcess (...) has been updated to completely read streams
after process has been completed.
The test was updated to run 5 times with different number of lines and line
sizes.
-
Commit messages:
- fixed num of iters
- fix
Changes: https://git.openjdk.org/jdk/
> The ProcessTools.startProcess (...) has been updated to completely read
> streams after process has been completed.
> The test was updated to run 5 times with different number of lines and line
> sizes.
Leonid Mesnik has updated the pull request incrementally with one additional
On Thu, 27 Apr 2023 04:59:00 GMT, David Holmes wrote:
>> Leonid Mesnik has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> fix
>
> test/lib-test/jdk/test/lib/process/ProcessToolsStartProc
> The ProcessTools.startProcess (...) has been updated to completely read
> streams after process has been completed.
> The test was updated to run 5 times with different number of lines and line
> sizes.
Leonid Mesnik has updated the pull request incrementally with one additional
On Thu, 27 Apr 2023 16:35:59 GMT, Leonid Mesnik wrote:
>> The ProcessTools.startProcess (...) has been updated to completely read
>> streams after process has been completed.
>> The test was updated to run 5 times with different number of lines and line
>> sizes.
>
> The ProcessTools.startProcess (...) has been updated to completely read
> streams after process has been completed.
> The test was updated to run 5 times with different number of lines and line
> sizes.
Leonid Mesnik has updated the pull request incrementally with one additional
On Thu, 27 Apr 2023 01:06:23 GMT, Leonid Mesnik wrote:
> The ProcessTools.startProcess (...) has been updated to completely read
> streams after process has been completed.
> The test was updated to run 5 times with different number of lines and line
> sizes.
This pull request
The ProcessTools has some support of jtreg thread factory functionality.
It tries to run the new process using virtual thread to run `main()` method.
This fix updates it to skip the java runs where no main class is involved and
more correctly process options which has 2nd argument.
Also is sets `m
Updated processtools to check exception after join().
Tested with running CI virtual thread tests.
-
Commit messages:
- 8307486: ProcessTools.java should wait until vthread is completed before
checking exceptions
Changes: https://git.openjdk.org/jdk/pull/13873/files
Webrev: https
ment.
> Also is sets `main.wrapper` property to allow launched process understand id
> any wrappers is used.
Leonid Mesnik has updated the pull request incrementally with one additional
commit since the last revision:
fixed some params
-
Changes:
- all: https://git.op
ment.
> Also is sets `main.wrapper` property to allow launched process understand id
> any wrappers is used.
Leonid Mesnik 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
On Thu, 4 May 2023 15:52:36 GMT, Leonid Mesnik wrote:
> The ProcessTools has some support of jtreg thread factory functionality.
> It tries to run the new process using virtual thread to run `main()` method.
> This fix updates it to skip the java runs where no main class is involved an
On Fri, 12 May 2023 00:05:21 GMT, Daniel D. Daugherty
wrote:
> A trivial fix to ProblemList java/util/concurrent/locks/Lock/OOMEInAQS.java
> on linux-x64.
Might be this failure is platform agnostic and should be generic all. We just
don't run this combination on macosx so often. (
--
On Fri, 12 May 2023 00:05:21 GMT, Daniel D. Daugherty
wrote:
> A trivial fix to ProblemList java/util/concurrent/locks/Lock/OOMEInAQS.java
> on linux-x64.
Marked as reviewed by lmesnik (Reviewer).
-
PR Review: https://git.openjdk.org/jdk/pull/13946#pullrequestreview-1423608862
Trivial fix that added missed useful command.
Tested by running make of failure handler and verifying results.
-
Commit messages:
- 8308223
Changes: https://git.openjdk.org/jdk/pull/14018/files
Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14018&range=00
Issue: https://bugs.op
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 pull request has now been integrated.
Changeset: 563152f3
Author:Leonid Mesnik
URL:
https://git.openj
On Sun, 21 May 2023 09:19:47 GMT, Jaikiran Pai wrote:
> Can I please get a review of this change which proposes to improve the
> accessibility of the thread dump files that are generated by the `jcmd
> Thread.dump_to_file` command configured in the failure handler
> configurations? This addres
On Thu, 23 Jun 2022 14:09:20 GMT, Roger Riggs wrote:
>> The RuntimeException from OutputAnalyzer for expected and unexpected exit
>> values should include both the actual and expected values.
>> The method `shouldHaveExitvalue` and `shouldNotHaveExitValue` include the
>> value expected and the
On Fri, 24 Jun 2022 18:51:40 GMT, Daniel D. Daugherty
wrote:
> A trivial fix to ProblemList tools/jlink/plugins/CompressorPluginTest.java.
Marked as reviewed by lmesnik (Reviewer).
-
PR: https://git.openjdk.org/jdk/pull/9285
On Thu, 7 Jul 2022 20:43:09 GMT, Coleen Phillimore wrote:
> This change uses sed to change sun.hotspot.WhiteBox to
> jdk.test.whitebox.Whitebox, and sun/hotspot/Whitebox similarly. Due to
> indirect inclusions of some of the test libraries, changing a few wasn't a
> reliable option, and I nee
On Fri, 8 Jul 2022 19:46:17 GMT, Coleen Phillimore wrote:
> This change removes the last remnants of sun/hotspot/WhiteBox.java and other
> classes, and uses the versions in jdk/test/whitebox.
> I used sed to change sun.hotspot.{gc,code,cpuinfo} to jdk.test.whitebox and
> deleted the old files a
On Tue, 12 Jul 2022 13:16:12 GMT, Daniel Jeliński wrote:
> `netstat -av` in Mac OS X failure handler is frequently running into the 20
> second timeout, leaving us with no socket information. This PR proposes
> running `netstat -anv` along with the existing `netstat -av`, so that we have
> at
Propagate test.vm.opts/test.java.opts to tested process. Also, accept the
output of non-generation (ZGC) GC as valid.
-
Commit messages:
- 8290846: sun/tools/jstatd/JstatdTest* tests should use VM options
Changes: https://git.openjdk.org/jdk/pull/9604/files
Webrev: https://webrevs
On Thu, 21 Jul 2022 23:01:55 GMT, Chris Plummer wrote:
>> Propagate test.vm.opts/test.java.opts to tested process. Also, accept the
>> output of non-generation (ZGC) GC as valid.
>
> test/jdk/sun/tools/jstatd/JstatGCUtilParser.java line 48:
>
>> 46: S0(GcStatisticsType.PERCENTAGE_OR_DAS
On Fri, 22 Jul 2022 00:52:37 GMT, Chris Plummer wrote:
>> Yes, ZGC reports dash for eden and survivor spaces.
>
> So shouldn't we have ZGC test failures then?
No, test passes with ZGC.
-
PR: https://git.openjdk.org/jdk/pull/9604
On Fri, 22 Jul 2022 19:27:29 GMT, Chris Plummer wrote:
>> No, test passes with ZGC.
>
> I meant shouldn't we see ZGC failures before your changes. Otherwise I don't
> understand why this change is needed.
Before my changes test just silently ignored any GC setting and always use G1.
--
On Thu, 21 Jul 2022 22:33:36 GMT, Leonid Mesnik wrote:
> Propagate test.vm.opts/test.java.opts to tested process. Also, accept the
> output of non-generation (ZGC) GC as valid.
This pull request has now been integrated.
Changeset: 348a0521
Author:Leonid Mesnik
URL:
On Tue, 2 Aug 2022 06:32:09 GMT, Ao Qi wrote:
>> `vmTestbase/nsk/jvmti/GetThreadInfo/thrinfo001/TestDescription.java` and
>> `vmTestbase/nsk/jvmti/RedefineClasses/StressRedefineVirtual/StressRedefineVirtual.java`
>> are added or modified by
>> [JDK-8284161](https://bugs.openjdk.org/browse/JDK-
The test should use the same locales in all processes, the default language
should work fine.
-
Commit messages:
- 8291081: Some sun/tools/jstatd/TestJstatd* tests fail with "Not a
percentage\: 68.31\: expected true, was false"
Changes: https://git.openjdk.org/jdk/pull/9798/files
On Mon, 8 Aug 2022 21:31:27 GMT, Chris Plummer wrote:
> Can you explain why setting the locale on the test but not the subprocess is
> causing the failure?
The jstatd process prints some numbers always using "en" locale and "." as
decimal separators. While reading process might have different
> The test should use the same locales in all processes, the default language
> should work fine.
Leonid Mesnik has updated the pull request incrementally with one additional
commit since the last revision:
fix
-
Changes:
- all: https://git.openjdk.org/jdk/pull/9798
On Tue, 9 Aug 2022 02:35:14 GMT, Leonid Mesnik wrote:
>> The test should use the same locales in all processes, the default language
>> should work fine.
>
> Leonid Mesnik has updated the pull request incrementally with one additional
> commit since the last revision:
&g
On Tue, 9 Aug 2022 21:14:39 GMT, Bill Huang wrote:
> This task converts 5 shell tests below to java version.
> test/java/lang/management/MemoryMXBean/LowMemoryTest2.sh
> test/java/lang/management/MemoryMXBean/MemoryManagementParallelGC.sh
> test/java/lang/management/MemoryMXBean/MemoryManageme
On Tue, 9 Aug 2022 21:14:39 GMT, Bill Huang wrote:
> This task converts 5 shell tests below to java version.
> test/java/lang/management/MemoryMXBean/LowMemoryTest2.sh
> test/java/lang/management/MemoryMXBean/MemoryManagementParallelGC.sh
> test/java/lang/management/MemoryMXBean/MemoryManageme
On Wed, 10 Aug 2022 18:50:51 GMT, Bill Huang wrote:
>> This task converts 5 shell tests below to java version.
>> test/java/lang/management/MemoryMXBean/LowMemoryTest2.sh
>> test/java/lang/management/MemoryMXBean/MemoryManagementParallelGC.sh
>> test/java/lang/management/MemoryMXBean/MemoryMan
On Wed, 10 Aug 2022 22:02:52 GMT, Bill Huang wrote:
>> This task converts 5 shell tests below to java version.
>> test/java/lang/management/MemoryMXBean/LowMemoryTest2.sh
>> test/java/lang/management/MemoryMXBean/MemoryManagementParallelGC.sh
>> test/java/lang/management/MemoryMXBean/MemoryMan
On Thu, 11 Aug 2022 20:02:06 GMT, Daniel D. Daugherty
wrote:
> A trivial fix so that Continuation/Fuzz.java honors the timeoutFactor JTREG
> setting
> when waiting for a compilation to finish.
>
> This fix is being tested in my jdk-20+10 stress testing run.
>
> The usual Mach5 timeoutFactor i
On Fri, 2 Jun 2023 21:30:46 GMT, Chris Plummer wrote:
> Normally when a virtual thread wrapper is used to run a test, the main thread
> is renamed to "old-m-a-i-n" and the new virtual thread that will act as the
> main thread is named "main". Neither is being done by `ProcessTools.main()`.
> T
On Fri, 23 Jun 2023 19:30:56 GMT, Daniel D. Daugherty
wrote:
> A trivial fix to ProblemList java/lang/ScopedValue/StressStackOverflow.java
> on generic-x64.
Changes requested by lmesnik (Reviewer).
test/jdk/ProblemList-Xcomp.txt line 31:
> 29:
> 30: java/lang/invoke/MethodHandles/CatchExcep
On Fri, 23 Jun 2023 19:30:56 GMT, Daniel D. Daugherty
wrote:
> A trivial fix to ProblemList java/lang/ScopedValue/StressStackOverflow.java
> on generic-x64.
Marked as reviewed by lmesnik (Reviewer).
-
PR Review: https://git.openjdk.org/jdk21/pull/60#pullrequestreview-1495844009
The test helper which spawn new jvms is updated to start them using VM flags
for testing.
-
Commit messages:
- 8314330: java/foreign tests should respect vm flags when start new processes
Changes: https://git.openjdk.org/jdk/pull/15302/files
Webrev: https://webrevs.openjdk.org/?re
> The test helper which spawn new jvms is updated to start them using VM flags
> for testing.
Leonid Mesnik has updated the pull request incrementally with one additional
commit since the last revision:
fixed imports.
-
Changes:
- all: https://git.openjdk.org/jdk/pull
On Wed, 16 Aug 2023 00:14:47 GMT, Leonid Mesnik wrote:
> The test helper which spawn new jvms is updated to start them using VM flags
> for testing.
This pull request has now been integrated.
Changeset: 7b28d360
Author:Leonid Mesnik
URL:
https://git.openjdk.org/jdk/
On Mon, 28 Aug 2023 15:54:08 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(/createJavaProcessBuilderI
1 - 100 of 189 matches
Mail list logo
