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
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
On Wed, 28 Feb 2024 01:18:50 GMT, Kim Barrett wrote:
> Please review this change that renames some test .h files to .hpp. These
> files contain C++ code and should be named accordingly. Some of them contain
> uses of NULL, which we change to nullptr.
>
> The renamed files are:
>
>
Tests updated to use jtreg vm flags.
Tested by running tests with different flags and tier1.
-
Commit messages:
- 8316451
Changes: https://git.openjdk.org/jdk/pull/17781/files
Webrev: https://webrevs.openjdk.org/?repo=jdk=17781=00
Issue:
There are several .sh tests which use ${TESTVMOPTS} only. Updated them to use
${TESTJAVAOPTS} also.
Tested by running them with different options and tier1.
-
Commit messages:
- 8319578: Few java/lang/instrument ignore test.java.opts and accept
test.vm.opts only
Changes:
On Wed, 24 Jan 2024 21:28:29 GMT, Leonid Mesnik wrote:
>> Some jtreg tests require resolvable external dependencies. This resolution
>> is delegated to JIB, which is not used in vanilla OpenJDK testing. It would
>> be convenient to add a keyword that marks tests that requ
On Mon, 15 Jan 2024 10:48:23 GMT, Aleksey Shipilev wrote:
> Some jtreg tests require resolvable external dependencies. This resolution is
> delegated to JIB, which is not used in vanilla OpenJDK testing. It would be
> convenient to add a keyword that marks tests that require these external
>
On Tue, 16 Jan 2024 09:01:35 GMT, Aleksey Shipilev wrote:
>> Since recent work to improve `tier4` performance, we actually test
>> `tier{1,2,3,4}` often, which includes all the tests in current tree. It
>> would be more convenient to just have the `all` test group/alias, so that we
>> can do
On Fri, 5 Jan 2024 09:07:57 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 process
On Fri, 5 Jan 2024 09:07:57 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 process
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
> that we
On Fri, 15 Dec 2023 10:49:56 GMT, Serguei Spitsyn wrote:
>> This fix is for JDK 23 but the intention is to back port it to 22 in RDP-1
>> time frame.
>> It is fixing a deadlock issue between `VirtualThread` class critical
>> sections with the `interruptLock` (in methods: `unpark()`,
On Fri, 8 Dec 2023 11:54:40 GMT, Serguei Spitsyn wrote:
>> This fix is for JDK 23 but the intention is to back port it to 22 in RDP-1
>> time frame.
>> It is fixing a deadlock issue between `VirtualThread` class critical
>> sections with the `interruptLock` (in methods: `unpark()`,
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 new java test
>> processes.
>>
On Mon, 4 Dec 2023 10:39:05 GMT, Darragh Clarke wrote:
> Updated tests to use vm.flagless as they already ignore Vm flags
Marked as reviewed by lmesnik (Reviewer).
-
PR Review: https://git.openjdk.org/jdk/pull/16946#pullrequestreview-1763304819
On Fri, 1 Dec 2023 00:58:57 GMT, Leonid Mesnik wrote:
> Description of problem and propsed fix from @plummercj
> '
> In test/failure_handler/src/share/conf/mac.properties we have:
>
> process.top.app=top
> process.top.args=-l 1
>
> So top is run with the "-l
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
On Fri, 1 Dec 2023 00:58:57 GMT, Leonid Mesnik wrote:
> Description of problem and propsed fix from @plummercj
> '
> In test/failure_handler/src/share/conf/mac.properties we have:
>
> process.top.app=top
> process.top.args=-l 1
>
> So top is run with the "-l
Description of problem and propsed fix from @plummercj
'
In test/failure_handler/src/share/conf/mac.properties we have:
process.top.app=top
process.top.args=-l 1
So top is run with the "-l 1" args, causing it to do one iteration and then
exit. Unfortunately the first iteration always shows all
On Thu, 16 Nov 2023 18:20:04 GMT, Mandy Chung wrote:
>> This PR includes test fixes for the following issues:
>>
>> 8319567: Update java/lang/invoke tests to support vm flags
>> 8319568: Update java/lang/reflect/exeCallerAccessTest/CallerAccessTest.java
>> to accept vm flags
>> 8319672:
On Wed, 15 Nov 2023 02:39:56 GMT, Mandy Chung wrote:
>> This PR includes test fixes for the following issues:
>>
>> 8319567: Update java/lang/invoke tests to support vm flags
>> 8319568: Update java/lang/reflect/exeCallerAccessTest/CallerAccessTest.java
>> to accept vm flags
>> 8319672:
On Fri, 10 Nov 2023 01:49:17 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.
>>
&
On Thu, 9 Nov 2023 22:08:06 GMT, Sandhya Viswanathan
wrote:
> Test jdk/incubator/vector/LoadJsvmlTest.java ignores VM flags and thus marked
> as flagless through @requires vm.flagless per
> [JDK-8319566](https://bugs.openjdk.org/browse/JDK-8319566).
Marked as reviewed by lmesnik (Reviewer).
On Fri, 10 Nov 2023 01:49:17 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.
>>
&
n the
> middle of the list. I don't think it makes sense to modify arguments in
> several places so I replaced it with the flag isLimited and moved all
> modifications in createJavaProcessBuilder().
>
> Testing tier1-5.
Leonid Mesnik has updated the pull request incrementally wit
On Wed, 8 Nov 2023 19:02:36 GMT, Mark Sheppard wrote:
>> Leonid Mesnik has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> converted list to array.
>
> test/lib/jdk/test/lib/process/ProcessTools.java line
n the
> middle of the list. I don't think it makes sense to modify arguments in
> several places so I replaced it with the flag isLimited and moved all
> modifications in createJavaProcessBuilder().
>
> Testing tier1-5.
Leonid Mesnik has updated the pull request incrementally wit
On Wed, 8 Nov 2023 02:33:29 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.
>>
&
n the
> middle of the list. I don't think it makes sense to modify arguments in
> several places so I replaced it with the flag isLimited and moved all
> modifications in createJavaProcessBuilder().
>
> Testing tier1-5.
Leonid Mesnik has updated the pull request incrementally wit
n the
> middle of the list. I don't think it makes sense to modify arguments in
> several places so I replaced it with the flag isLimited and moved all
> modifications in createJavaProcessBuilder().
>
> Testing tier1-5.
Leonid Mesnik has updated the pull request with a n
On Wed, 25 Oct 2023 21:08:01 GMT, Leonid Mesnik wrote:
> The jtreg starts the main thread in a separate ThreadGroup and checks
> unhandled exceptions for this group. However, it doesn't catch all unhandled
> exceptions. There is a jtreg issue for this
> https://bugs.openjd
On Fri, 3 Nov 2023 03:44:31 GMT, Leonid Mesnik wrote:
>> The jtreg starts the main thread in a separate ThreadGroup and checks
>> unhandled exceptions for this group. However, it doesn't catch all unhandled
>> exceptions. There is a jtreg issue for this
>> https:/
On Fri, 3 Nov 2023 03:44:31 GMT, Leonid Mesnik wrote:
>> The jtreg starts the main thread in a separate ThreadGroup and checks
>> unhandled exceptions for this group. However, it doesn't catch all unhandled
>> exceptions. There is a jtreg issue for this
>> https:/
> test/jdk/java/util/concurrent/tck/ThreadTest.java is updated to not check the
> default empty handler.
>
> Probably, we need some common approach about dealing with the
> UncaughtExceptionHandler in jtreg.
Leonid Mesnik has updated the pull request incrementally with one additi
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 factory requires the injection of arguments in the
middle of the list.
On Tue, 31 Oct 2023 07:43:43 GMT, Leo Korinth wrote:
> Changing from `Class c` to `Class c` removes two warnings.
Marked as reviewed by lmesnik (Reviewer).
-
PR Review: https://git.openjdk.org/jdk/pull/16431#pullrequestreview-1707376126
On Sun, 29 Oct 2023 14:10:32 GMT, Jaikiran Pai wrote:
>> The jtreg starts the main thread in a separate ThreadGroup and checks
>> unhandled exceptions for this group. However, it doesn't catch all unhandled
>> exceptions. There is a jtreg issue for this
>>
On Fri, 27 Oct 2023 05:55:43 GMT, David Holmes wrote:
>> It is still used in tests and we should ignore it like jtreg doing.
>
> Shouldn't this code first retrieve the current default exception handler, and
> then check whether t is a virtual thread, and if so handle the exception as
>
On Thu, 26 Oct 2023 08:34:39 GMT, Alan Bateman wrote:
> Having a UHE invoke System.exit is surprising. Are you saying that this is
> only for cases where a test launches a child VM with the thread factory set?
It is for cases when the test is started in a virtual thread. I don't see a
better
On Thu, 26 Oct 2023 08:34:39 GMT, Alan Bateman wrote:
> Stepping back a bit. ThreadGroup is legacy and we eventually want it to go
> away. We've been deprecating and degrading it very slowly over many releases.
> So I think jtreg will eventually need to change. Right now, it creates
>
On Wed, 25 Oct 2023 21:08:01 GMT, Leonid Mesnik wrote:
> The jtreg starts the main thread in a separate ThreadGroup and checks
> unhandled exceptions for this group. However, it doesn't catch all unhandled
> exceptions. There is a jtreg issue for this
> https://bugs.openjd
On Thu, 26 Oct 2023 06:09:34 GMT, Jaikiran Pai wrote:
>> The jtreg starts the main thread in a separate ThreadGroup and checks
>> unhandled exceptions for this group. However, it doesn't catch all unhandled
>> exceptions. There is a jtreg issue for this
>>
The jtreg starts the main thread in a separate ThreadGroup and checks unhandled
exceptions for this group. However, it doesn't catch all unhandled exceptions.
There is a jtreg issue for this
https://bugs.openjdk.org/browse/CODETOOLS-7903526.
Catching such issues for virtual threads is important
On Tue, 24 Oct 2023 07:49:30 GMT, Leo Korinth wrote:
>> This pull request renames `createJavaProcessBuilder` to
>> `createLimitedTestJavaProcessBuilder` and renames `createTestJvm` to
>> `createTestJavaProcessBuilder`. Both are implemented through a private
>> `createJavaProcessBuilder`. It
The test uses specific classpath, and jar and is intended to test modules. So I
marked is as flagless,
-
Commit messages:
- 8316452
Changes: https://git.openjdk.org/jdk/pull/16080/files
Webrev: https://webrevs.openjdk.org/?repo=jdk=16080=00
Issue:
I marked tests
sun/tools/jcmd/TestProcessHelper.java
sun/tools/jinfo/JInfoTest.java
as headless. They used different specific VM options and are not worth
executing with other VM flags.
And fixed
sun/tools/jstat/JStatInterval.java
Tested with tier1, local execution of tests, and running
Test
com/sun/management/HotSpotDiagnosticMXBean/CheckOrigin.java
check how beans work with VM flags and ignore external flags.
It doesn't make sense to run it with external options so just mark it as
flagless.
Tested with running tier1 and test with/without additional options.
-
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
>
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/
> 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
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:
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
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:
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()`.
>
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
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
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=14018=00
Issue:
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
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 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
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
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
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:
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
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.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 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
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:
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.
>
> This fix p
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
>
; 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://git.openj
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
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
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
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.
>
> This fix p
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
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
t 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 with iss
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.
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
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 ju
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 ju
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
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
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
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 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 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 now been integrated.
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 run
> 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
commit since the last
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
commit since the last
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 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
commit since the last
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.
>
> Leonid Mesnik has
> 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
commit since the last
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:
1 - 100 of 139 matches
Mail list logo
