Thanks for your comments. I incorporated them in the updated version of the JEP
and updated all related repositories that now are implemented based on current
JDK20 head and async-profiler head. The implementation of the JEP now resides
in the sandbox repository too.
Regards
Johannes
From: Ma
This test duplicates runtime/handshake/HandshakeSuspendExitTest.java and might
be deleted.
-
Commit messages:
- fix
Changes: https://git.openjdk.org/jdk/pull/10662/files
Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10662&range=00
Issue: https://bugs.openjdk.org/browse/JDK-82
On Tue, 11 Oct 2022 16:46:37 GMT, Leonid Mesnik wrote:
> This test duplicates runtime/handshake/HandshakeSuspendExitTest.java and
> might be deleted.
I think, the failing status is a test issue but it is hard to prove.
This test is over complicated and hard to understand and work with.
Addition
On Fri, 30 Sep 2022 11:00:28 GMT, Kevin Walls wrote:
> Set the management.properties
> "com.sun.management.jmxremote.serial.filter.pattern" value by default, to
> restrict types that can be deserialized.
>
> Use the example value from the Core Libraries guide (see section 2.
> Serialization
On Mon, 10 Oct 2022 21:54:09 GMT, Chris Plummer wrote:
>> The main issues I set out to address are:
>>
>> - legacy Solaris references can be removed
>> - add help with dealing with Windows core files, most of important of which
>> is use of PATH to find the dlls referenced by the core file.
>>
On Fri, 30 Sep 2022 23:30:41 GMT, Chris Plummer wrote:
> The main issues I set out to address are:
>
> - legacy Solaris references can be removed
> - add help with dealing with Windows core files, most of important of which
> is use of PATH to find the dlls referenced by the core file.
> - add
On Thu, 6 Oct 2022 10:23:04 GMT, Roman Kennke wrote:
> This change replaces the current stack-locking implementation with a
> fast-locking scheme that retains the advantages of stack-locking (namely fast
> locking in uncontended code-paths), while avoiding the overload of the mark
> word. That
On Tue, 11 Oct 2022 16:46:37 GMT, Leonid Mesnik wrote:
> This test duplicates runtime/handshake/HandshakeSuspendExitTest.java and
> might be deleted.
I don't think that this test:
serviceability/jvmti/thread/SuspendThread/suspendthrd03/suspendthrd03.java
duplicates:
runtime/handshake/Handsh
On Tue, 11 Oct 2022 18:28:27 GMT, Daniel D. Daugherty
wrote:
> I'm okay with deleting these two files:
>
> test/hotspot/jtreg/serviceability/jvmti/thread/SuspendThread/suspendthrd03/libsuspendthrd03.cpp
>
> test/hotspot/jtreg/serviceability/jvmti/thread/SuspendThread/suspendthrd03/suspendthrd
On Tue, 11 Oct 2022 16:46:37 GMT, Leonid Mesnik wrote:
> This test duplicates runtime/handshake/HandshakeSuspendExitTest.java and
> might be deleted.
Marked as reviewed by dcubed (Reviewer).
I'm okay with deleting these two files:
test/hotspot/jtreg/serviceability/jvmti/thread/SuspendThread/s
On Tue, 11 Oct 2022 18:35:06 GMT, Leonid Mesnik wrote:
> The idea was to improve these tests to test virtual threads.
> However, the suspend/resume have already some coverage in vthread.
In fact, we have pretty extensive SR test coverage for virtual threads.
-
PR: https://git.openj
The fix removes nsk/jvmti/ tests ported to serviceability/jvmti and
forward-ports corresponding fixed. The suspend/resume tests require more work
covered by https://bugs.openjdk.org/browse/JDK-8295169.
-
Commit messages:
- fix
Changes: https://git.openjdk.org/jdk/pull/10665/files
> This change replaces the current stack-locking implementation with a
> fast-locking scheme that retains the advantages of stack-locking (namely fast
> locking in uncontended code-paths), while avoiding the overload of the mark
> word. That overloading causes massive problems with Lilliput, bec
> This change replaces the current stack-locking implementation with a
> fast-locking scheme that retains the advantages of stack-locking (namely fast
> locking in uncontended code-paths), while avoiding the overload of the mark
> word. That overloading causes massive problems with Lilliput, bec
On Tue, 11 Oct 2022 13:25:30 GMT, Aleksey Shipilev wrote:
>> Roman Kennke has updated the pull request incrementally with two additional
>> commits since the last revision:
>>
>> - Merge remote-tracking branch 'origin/fast-locking' into fast-locking
>> - Re-use r0 in call to unlock_object()
>
On Tue, 11 Oct 2022 20:01:32 GMT, Roman Kennke wrote:
>> This change replaces the current stack-locking implementation with a
>> fast-locking scheme that retains the advantages of stack-locking (namely
>> fast locking in uncontended code-paths), while avoiding the overload of the
>> mark word.
On Tue, 11 Oct 2022 19:00:11 GMT, Leonid Mesnik wrote:
> The fix removes nsk/jvmti/ tests ported to serviceability/jvmti and
> forward-ports corresponding fixed. The suspend/resume tests require more work
> covered by https://bugs.openjdk.org/browse/JDK-8295169.
Can you update the CR to point
There are a few changes we can make to better understand the LingeredApp test
when it goes wrong:
startAppExactJvmOpts() should not try and call finishApp unless the process
isAlive, that just creates a misleading exception.
waitAppReady() is really waitAppReadyOrCrashed(), and should not timeo
On Tue, 11 Oct 2022 19:00:11 GMT, Leonid Mesnik wrote:
> The fix removes nsk/jvmti/ tests ported to serviceability/jvmti and
> forward-ports corresponding fixed. The suspend/resume tests require more work
> covered by https://bugs.openjdk.org/browse/JDK-8295169.
The tests were ported as a par
19 matches
Mail list logo
