On Wed, 13 Mar 2024 01:02:50 GMT, Alex Menkov wrote:
>> RecordComponent class has _attributes_count field.
>> The only user of the field is JvmtiClassFileReconstituter. Incorrect value
>> of the field causes producing incorrect data for Record attribute.
>> Parsing Record attribute
On Wed, 13 Mar 2024 01:02:50 GMT, Alex Menkov wrote:
>> RecordComponent class has _attributes_count field.
>> The only user of the field is JvmtiClassFileReconstituter. Incorrect value
>> of the field causes producing incorrect data for Record attribute.
>> Parsing Record attribute
On Mon, 26 Feb 2024 22:55:06 GMT, Jiangli Zhou wrote:
>> Please help review this trivial fix for resolving `ld: error: duplicate
>> symbol: closeDescriptors` when static linking with both libjdwp and libjava,
>> thanks.
>
> Jiangli Zhou has updated the pull request incrementally with two
On Wed, 21 Feb 2024 21:42:08 GMT, Alex Menkov wrote:
>> VirtualMachine.loadAgentPath/loadAgentLibrary can fail with
>> AgentLoadException in 2 cases:
>> - attach listener returns error; in the case the exception is thrown from
>> HotSpotVirtualMachine.processCompletionStatus (called from
>>
The implementation of the JVM TI `GetCurrentContendedMonitor` does not match
the spec. It can sometimes return an incorrect information about the contended
monitor. Such a behavior does not match the function spec.
With this update the `GetCurrentContendedMonitor` is returning the monitor only
On Mon, 8 Jan 2024 07:55:45 GMT, Serguei Spitsyn wrote:
> The notification method `VirtualThread.notifyJvmtiDisableSuspend` should be
> static.
> The method disables/enables suspend of the current virtual thread, a no-op if
> the current thread is a platform thread. It
On Thu, 11 Jan 2024 13:09:39 GMT, Serguei Spitsyn wrote:
>> The notification method `VirtualThread.notifyJvmtiDisableSuspend` should be
>> static.
>> The method disables/enables suspend of the current virtual thread, a no-op
>> if the current thread is a platform
On Thu, 11 Jan 2024 13:09:39 GMT, Serguei Spitsyn wrote:
>> The notification method `VirtualThread.notifyJvmtiDisableSuspend` should be
>> static.
>> The method disables/enables suspend of the current virtual thread, a no-op
>> if the current thread is a platform
s to use the
> argument #0 instead of #1.
>
> Testing:
> - The mach5 tiers 1-6 show no regressions
Serguei Spitsyn 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. T
On Wed, 20 Dec 2023 21:28:04 GMT, Serguei Spitsyn wrote:
> Hi all,
>
> This pull request contains a backport of commit
> [0f8e4e0a](https://github.com/openjdk/jdk/commit/0f8e4e0a81257c678e948c341a241dc0b810494f)
> from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
On Wed, 20 Dec 2023 21:28:04 GMT, Serguei Spitsyn wrote:
> Hi all,
>
> This pull request contains a backport of commit
> [0f8e4e0a](https://github.com/openjdk/jdk/commit/0f8e4e0a81257c678e948c341a241dc0b810494f)
> from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
On Wed, 20 Dec 2023 21:28:04 GMT, Serguei Spitsyn wrote:
> Hi all,
>
> This pull request contains a backport of commit
> [0f8e4e0a](https://github.com/openjdk/jdk/commit/0f8e4e0a81257c678e948c341a241dc0b810494f)
> from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
On Mon, 8 Jan 2024 09:04:57 GMT, Alan Bateman wrote:
>> In preparation for when virtual threads can unmount while holding a monitor
>> or unmount when blocking on monitorenter, the implementation of
>> VirtualThread's interrupt method is refactored to avoid parking/blocking
>> while holding
The notification method `VirtualThread.notifyJvmtiDisableSuspend` should be
static.
The method disables/enables suspend of the current virtual thread, a no-op if
the current thread is a platform thread. It is confusing for this to be an
instance method, it should be static to make it clearer
Hi all,
This pull request contains a backport of commit
[0f8e4e0a](https://github.com/openjdk/jdk/commit/0f8e4e0a81257c678e948c341a241dc0b810494f)
from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
The commit being backported was authored by Serguei Spitsyn on 19 Dec 2023
On Wed, 20 Dec 2023 14:15:48 GMT, Alan Bateman wrote:
> Update: ignore this I mis-read that it updates the current thread's suspend
> value, not the thread's suspend value.
Thanks, Alan. I've also got confused with this and even filed a follow up bug.
:)
Yes, the initial design was the
On Wed, 20 Dec 2023 08:02:14 GMT, Alan Bateman wrote:
>> src/hotspot/share/prims/jvm.cpp line 4024:
>>
>>> 4022: #else
>>> 4023: fatal("Should only be called with JVMTI enabled");
>>> 4024: #endif
>>
>> You can't do this! The Java code knows nothing about JVM TI being
>> enabled/disabled
On Thu, 7 Dec 2023 06:28:43 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, 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
ty/jvmti/vthread/SuspendWithInterruptLock`
> The test is very nice as it reliably in 100% reproduces the deadlock without
> the fix.
> The test is never failing with this fix.
>
> Testing:
> - tested with newly added test:
> `test/hotspot/jtreg/serviceability/jvmti/vthread/SuspendWi
On Fri, 15 Dec 2023 08:57:45 GMT, Alan Bateman wrote:
>> Serguei Spitsyn has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> review: moved a couple of comments out of try blocks
>
> src/hotspot/share/prims
ty/jvmti/vthread/SuspendWithInterruptLock`
> The test is very nice as it reliably in 100% reproduces the deadlock without
> the fix.
> The test is never failing with this fix.
>
> Testing:
> - tested with newly added test:
> `test/hotspot/jtreg/serviceability/jvmti/vthread/SuspendWi
On Thu, 14 Dec 2023 22:35:18 GMT, Serguei Spitsyn wrote:
>> src/java.base/share/classes/java/lang/VirtualThread.java line 1043:
>>
>>> 1041: notifyJvmtiDisableSuspend(true);
>>> 1042: try {
>>> 1043: // include
ty/jvmti/vthread/SuspendWithInterruptLock`
> The test is very nice as it reliably in 100% reproduces the deadlock without
> the fix.
> The test is never failing with this fix.
>
> Testing:
> - tested with newly added test:
> `test/hotspot/jtreg/serviceability/jvmti/vthread/SuspendWi
On Thu, 14 Dec 2023 19:50:00 GMT, Alan Bateman wrote:
>> Serguei Spitsyn has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> review: moved notifyJvmtiDisableSuspend(true) out of try-block
>
> src/jav
On Thu, 14 Dec 2023 18:03:00 GMT, Alan Bateman wrote:
>> Serguei Spitsyn has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> review: 1) replace CriticalLock with DisableSuspend; 2) minor tweaks
>
> src/jav
On Thu, 14 Dec 2023 12:16:34 GMT, Serguei Spitsyn wrote:
>> src/hotspot/share/runtime/javaThread.hpp line 320:
>>
>>> 318: bool _is_in_VTMS_transition; // thread is
>>> in virtual thread mount st
On Thu, 14 Dec 2023 18:04:02 GMT, Alan Bateman wrote:
> Okay with me. We'll need to move the notifyJvmtiDisableSuspend(true) to
> before the try in all cases, I've pointed out the cases that we missed.
Thank you, Alan. Fixed now.
-
PR Comment:
ty/jvmti/vthread/SuspendWithInterruptLock`
> The test is very nice as it reliably in 100% reproduces the deadlock without
> the fix.
> The test is never failing with this fix.
>
> Testing:
> - tested with newly added test:
> `test/hotspot/jtreg/serviceability/jvmti/vthread/SuspendWi
On Thu, 14 Dec 2023 17:06:05 GMT, Alan Bateman wrote:
>> Implemented this renaming suggestion. Let's wait if Alan ia okay with it.
>
>> Implemented this renaming suggestion. Let's wait if Alan ia okay with it.
>
> Are you planning to drop the changes to mount/unmount too? They shouldn't be
>
ty/jvmti/vthread/SuspendWithInterruptLock`
> The test is very nice as it reliably in 100% reproduces the deadlock without
> the fix.
> The test is never failing with this fix.
>
> Testing:
> - tested with newly added test:
> `test/hotspot/jtreg/serviceability/jvmti/vthread/SuspendWi
On Thu, 14 Dec 2023 12:11:42 GMT, Serguei Spitsyn wrote:
>> src/java.base/share/classes/java/lang/VirtualThread.java line 1164:
>>
>>> 1162:
>>> 1163: @IntrinsicCandidate
>>> 1164: private native void notifyJvmtiCriticalLock(boolean ent
On Tue, 12 Dec 2023 23:54:43 GMT, Leonid Mesnik wrote:
>> Serguei Spitsyn has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> review: (1) rename notifyJvmti method; (2) add try-final statements to
>> Virtual
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
On Tue, 12 Dec 2023 23:42:07 GMT, Leonid Mesnik wrote:
>> Serguei Spitsyn has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> review: (1) rename notifyJvmti method; (2) add try-final statements to
>> VirtualTh
ty/jvmti/vthread/SuspendWithInterruptLock`
> The test is very nice as it reliably in 100% reproduces the deadlock without
> the fix.
> The test is never failing with this fix.
>
> Testing:
> - tested with newly added test:
> `test/hotspot/jtreg/serviceability/jvmti/vthread/SuspendWi
ty/jvmti/vthread/SuspendWithInterruptLock`
> The test is very nice as it reliably in 100% reproduces the deadlock without
> the fix.
> The test is never failing with this fix.
>
> Testing:
> - tested with newly added test:
> `test/hotspot/jtreg/serviceability/jvmti/vthread/SuspendWi
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()`, `interrupt()`,
`getAndClearInterrupt()`, `threadState()`, `toString()`),
On Tue, 5 Dec 2023 09:51:50 GMT, Alan Bateman wrote:
>> When a virtual thread continues after Thread.yield it currently consumes
>> thread's parking permit. This is an oversight, the parking permit should
>> only be consumed when continuing after park.
>>
>> The changes are straight-forward.
On Mon, 4 Dec 2023 16:08:32 GMT, Alan Bateman wrote:
> When a virtual thread continues after Thread.yield it currently consumes
> thread's parking permit. This is an oversight, the parking permit should only
> be consumed when continuing after park.
>
> The changes are straight-forward. The
On Mon, 4 Dec 2023 16:08:32 GMT, Alan Bateman wrote:
> When a virtual thread continues after Thread.yield it currently consumes
> thread's parking permit. This is an oversight, the parking permit should only
> be consumed when continuing after park.
>
> The changes are straight-forward. The
On Thu, 23 Nov 2023 09:18:44 GMT, Alan Bateman wrote:
> The deadlock prone Thread/ThreadGroup suspend/resume were deprecated since
> JDK 1.2, deprecated for removal in Java 14, and re-specified/degraded to
> throw UnsupportedOperationException unconditionally in Java 19/20. Early in
> Java
On Thu, 23 Nov 2023 09:18:44 GMT, Alan Bateman wrote:
> The deadlock prone Thread/ThreadGroup suspend/resume were deprecated since
> JDK 1.2, deprecated for removal in Java 14, and re-specified/degraded to
> throw UnsupportedOperationException unconditionally in Java 19/20. Early in
> Java
On Mon, 4 Sep 2023 08:24:19 GMT, Alan Bateman wrote:
>> In the virtual thread implementation, thread identity switches to the
>> carrier before freezing and switches back to the virtual thread after
>> thawing. This was a forced move due to issues getting JVMTI to work with
>> virtual
On Mon, 4 Sep 2023 08:24:19 GMT, Alan Bateman wrote:
>> In the virtual thread implementation, thread identity switches to the
>> carrier before freezing and switches back to the virtual thread after
>> thawing. This was a forced move due to issues getting JVMTI to work with
>> virtual
On Thu, 24 Aug 2023 21:38:41 GMT, Kevin Walls wrote:
>> Several tests from test/jdk/sun/tools/jstatd are intermittent.
>>
>> Port clashes when run at the same time on the same machine have been a
>> problem.
>> The RMI error "no such object in table" can mean a reference on the RMI
>> server
On Wed, 9 Aug 2023 11:06:04 GMT, Matthias Baesken wrote:
>> There is coding e.g. in
>> https://github.com/openjdk/jdk/blob/master/test/jdk/jdk/jfr/event/runtime/TestNativeLibrariesEvent.java#L72
>> that deals with shared lib naming on different OS.
>> This code should be simplified.
>
> Matthias
On Fri, 4 Aug 2023 18:34:52 GMT, Chris Plummer wrote:
>> There is coding e.g. in
>> https://github.com/openjdk/jdk/blob/master/test/jdk/jdk/jfr/event/runtime/TestNativeLibrariesEvent.java#L72
>> that deals with shared lib naming on different OS.
>> This code should be simplified.
>
>
On Fri, 21 Jul 2023 18:01:45 GMT, Alan Bateman wrote:
> Thread::getState is an API for monitoring and management purposes to report
> the thread state. If a virtual thread is parked with LockSupport.parkNanos,
> its state is reported as WAITING when it should be TIMED_WAITING. JVM TI
>
On Fri, 21 Jul 2023 18:01:45 GMT, Alan Bateman wrote:
> Thread::getState is an API for monitoring and management purposes to report
> the thread state. If a virtual thread is parked with LockSupport.parkNanos,
> its state is reported as WAITING when it should be TIMED_WAITING. JVM TI
>
On Wed, 26 Jul 2023 17:38:24 GMT, Alan Bateman wrote:
>> I can't see why it would be needed.
>
>> It would be nice to add a short comment why this is needed.
>
> It's not needed here, it was needed in another version of the tests. While
> benign, I can remove it to avoid any confusion. Thanks.
On Fri, 21 Jul 2023 18:01:45 GMT, Alan Bateman wrote:
> Thread::getState is an API for monitoring and management purposes to report
> the thread state. If a virtual thread is parked with LockSupport.parkNanos,
> its state is reported as WAITING when it should be TIMED_WAITING. JVM TI
>
On Fri, 30 Jun 2023 08:11:47 GMT, Matthias Baesken wrote:
> Most G1 tests set -XX:+UseG1GC, but a few (e.g.
> gc/g1/TestVerificationInConcurrentCycle.java) miss that.
> This is usually just fine and no problem because G1 is the default anyway.
> However in some cases, where a custom JVM changes
On Wed, 14 Jun 2023 04:53:58 GMT, David Holmes wrote:
> Updated the version to 22-ea and year to 2024.
>
> The following unpublished changes will also be included in this update:
> - [JDK-8290626](https://bugs.openjdk.org/browse/JDK-8290626): keytool manpage
> contains a special character
> -
On Fri, 9 Jun 2023 13:39:26 GMT, Matthias Baesken wrote:
> On AIX , new jtreg test
> com/sun/tools/attach/warnings/DynamicLoadWarningTest.java always failed with
> the output :
>
> --System.err:(294/28579)--
> STARTED DynamicLoadWarningTest::testLoadJavaAgent
On Sat, 3 Jun 2023 21:34:16 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
>>
The VM option EnableDynamicAgentLoading was added in JDK 9, default true, to
allow deployment to choose whether to allow agents to be loaded/started in the
VM. The VM option does the right thing for tools using the Attach API but jcmd
JVMTI.agent_load was missed. This should be fixed to
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 `notifyJvmtiEven
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 preserve process
On Tue, 25 Apr 2023 15:50:24 GMT, Daniel D. Daugherty
wrote:
>> Agree, it is confusing, even in standard j.l.Process API . The `InputStream
>> java.lang.Process.getInputStream()`" returns **output** stream of started
>> process. So for our implementation ProcessImpl the 'out' and 'err' mean
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 preserve process
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 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 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 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 Thu, 23 Mar 2023 09:10:26 GMT, Serguei Spitsyn wrote:
> The fix was suggested/provided by @AlanBateman.
> Continuation should use Unsafe.compareAndSetReference rather than a VH here.
> We had to change CHM and VT back to Unsafe for similar reasons.
>
> Testing: Mach5 ru
On Thu, 23 Mar 2023 09:10:26 GMT, Serguei Spitsyn wrote:
> The fix was suggested/provided by @AlanBateman.
> Continuation should use Unsafe.compareAndSetReference rather than a VH here.
> We had to change CHM and VT back to Unsafe for similar reasons.
>
> Testing: Mach5 ru
On Thu, 23 Mar 2023 09:10:26 GMT, Serguei Spitsyn wrote:
> The fix was suggested/provided by @AlanBateman.
> Continuation should use Unsafe.compareAndSetReference rather than a VH here.
> We had to change CHM and VT back to Unsafe for similar reasons.
>
> Testing: Mach5 ru
The fix was suggested/provided by @AlanBateman.
Continuation should use Unsafe.compareAndSetReference rather than a VH here.
We had to change CHM and VT back to Unsafe for similar reasons.
Testing: Mach5 runs of tiers 1-6 are in progress
-
Commit messages:
- 8304448: Kitchensink
On Thu, 16 Mar 2023 05:03:51 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:
> `not
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:
On Sat, 18 Mar 2023 11:24:47 GMT, Alan Bateman wrote:
> The most important case is when there is no JVMTI env. If I read the changes
> correctly, the overhead for park/continue changes from one volatile-read
> (notifyJvmtiEvents) to two plain-writes (JavaThread::_is_in_VTMS_transition).
>
>
On Fri, 17 Mar 2023 17:33:46 GMT, Vladimir Ivanov wrote:
> Overall, compiler changes look good.
> Any performance numbers to justify the intrinsification?
Thank you for review and your guidance and help with C2 intrinsification!
My goal was to move the notifyJvmtiEvents checks from Java to VM
ifyJvmtiEvents` variable.
>
> Implementing the same methods as C1 intrinsics can be needed in the future
> but is a low priority for now.
>
> Testing:
> - Ran mach5 tiers 1-6. No regressions were found.
Serguei Spitsyn has updated the pull request incremental
ifyJvmtiEvents` variable.
>
> Implementing the same methods as C1 intrinsics can be needed in the future
> but is a low priority for now.
>
> Testing:
> - Ran mach5 tiers 1-6. No regressions were found.
Serguei Spitsyn has updated the pull request incrementa
ifyJvmtiEvents` variable.
>
> Implementing the same methods as C1 intrinsics can be needed in the future
> but is a low priority for now.
>
> Testing:
> - Ran mach5 tiers 1-6. No regressions were found.
Serguei Spitsyn has updated the pull request incrementally wi
This is needed for performance improvements in support of virtual threads.
The update includes the following:
1. Refactored the `VirtualThread` native methods:
`notifyJvmtiMountBegin` and `notifyJvmtiMountEnd` =>
`notifyJvmtiMount`
`notifyJvmtiUnmountBegin` and
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
>> fiel
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
>> fiel
On Tue, 27 Dec 2022 14:26:39 GMT, Michael Ernst wrote:
>> 8294321: Fix typos in files under test/jdk/java, test/jdk/jdk, test/jdk/jni
>
> Michael Ernst has updated the pull request with a new target base due to a
> merge or a rebase. The pull request now contains seven commits:
>
> - Merge
On Tue, 27 Dec 2022 14:26:39 GMT, Michael Ernst wrote:
>> 8294321: Fix typos in files under test/jdk/java, test/jdk/jdk, test/jdk/jni
>
> Michael Ernst has updated the pull request with a new target base due to a
> merge or a rebase. The pull request now contains seven commits:
>
> - Merge
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
>> fiel
On Thu, 1 Dec 2022 05:44:44 GMT, Joe Darcy wrote:
>> Similar to an update recently done for langtools tests, update the libraries
>> regression tests to take advantage of the @enablePreview jtreg feature.
>
> Joe Darcy has updated the pull request with a new target base due to a merge
> or a
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
>> fiel
On Wed, 23 Nov 2022 10:31:00 GMT, Alan Bateman wrote:
>> Fixed the `yieldContinuation()` method.
>> There is also `switchToCarrierThread()` method that returns the
>> `notifyJvmtiEvents` value.
>> It seems to be an optimization. I'm not sure yet, if we need to fix these
>> places as well.
>
>>
On Wed, 23 Nov 2022 10:01:07 GMT, Serguei Spitsyn wrote:
>> src/java.base/share/classes/java/lang/VirtualThread.java line 273:
>>
>>> 271: private void run(Runnable task) {
>>> 272: assert state == RUNNING;
>>> 273: boolean notifyJvm
MSTransitionDisabler helper for sync.
>
> Testing:
> The originally failed tests are passed now:
>
> runtime/vthread/RedefineClass.java
> runtime/vthread/TestObjectAllocationSampleEvent.java
>
> In progress:
> Run the tiers 1-6 to make sure there are no regression.
Serg
On Wed, 23 Nov 2022 02:17:43 GMT, Leonid Mesnik 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
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 been set to `true` when an agent library is loaded into running VM.
The
irtualStartThreadTest.
> TBD: mach5 jvmti, jdi and tier1-6 tests.
Serguei Spitsyn has updated the pull request incrementally with one additional
commit since the last revision:
roll back unintended VirtualThread.java file update
-
Changes:
- all: https://git.openjdk.org/jdk/
The can_support_virtual_thread was initially implemented as an onload
capability.
It is why this capability does not work for the agents loaded into running VM.
The fix is to move it from `onload` to `always`capabilities list.
Testing:
New test is added: VirtualStartThreadTest.
TBD: mach5 jvmti,
On Mon, 7 Nov 2022 20:40:33 GMT, Coleen Phillimore wrote:
>> This patch moves the acquisition of the boot class loader lock out of the
>> JVM and into the Java function.
>> Tested with tier1-4, and jvmti and jdi tests locally.
>
> Coleen Phillimore has updated the pull request incrementally
On Tue, 15 Nov 2022 18:52:37 GMT, Coleen Phillimore wrote:
>> The JVM code took a ThreadGroup lock before poking into ThreadGroup fields.
>> Call a method in the ThreadGroup to call the synchronized method instead.
>> Tested with tier 1-4.
>
> Coleen Phillimore has updated the pull request
On Wed, 9 Nov 2022 09:49:10 GMT, Alan Bateman wrote:
>> src/hotspot/share/prims/jvmtiEnvBase.cpp line 557:
>>
>>> 555: JvmtiEnvBase::new_jthreadGroupArray(int length, objArrayHandle groups)
>>> {
>>> 556: if (length == 0) {
>>> 557: return NULL;
>>
>> I do not think returning NULL is
On Tue, 8 Nov 2022 18:20:34 GMT, Bill Huang wrote:
>> There is no new changes in the open portion of JDK, but extracting common
>> functionalities in bootstrap Utils to test/lib/Utils which can be used in
>> the closed part.
>
> Bill Huang has updated the pull request incrementally with one
On Tue, 8 Nov 2022 14:55:17 GMT, Coleen Phillimore wrote:
>> The JVM code took a ThreadGroup lock before poking into ThreadGroup fields.
>> Call a method in the ThreadGroup to call the synchronized method instead.
>> Tested with tier 1-4.
>
> Coleen Phillimore has updated the pull request
On Tue, 8 Nov 2022 14:55:17 GMT, Coleen Phillimore wrote:
>> The JVM code took a ThreadGroup lock before poking into ThreadGroup fields.
>> Call a method in the ThreadGroup to call the synchronized method instead.
>> Tested with tier 1-4.
>
> Coleen Phillimore has updated the pull request
On Tue, 8 Nov 2022 00:58:44 GMT, Coleen Phillimore wrote:
> The JVM code took a ThreadGroup lock before poking into ThreadGroup fields.
> Call a method in the ThreadGroup to call the synchronized method instead.
> Tested with tier 1-4.
This looks nice in general.
But I will make another pass.
On Mon, 7 Nov 2022 19:23:05 GMT, Bill Huang wrote:
> There is no new changes in the open portion of JDK, but extracting common
> functionalities in bootstrap Utils to test/lib/Utils which can be used in the
> closed part.
test/lib/jdk/test/lib/Utils.java line 1007:
> 1005:
On Mon, 7 Nov 2022 19:23:05 GMT, Bill Huang wrote:
> There is no new changes in the open portion of JDK, but extracting common
> functionalities in bootstrap Utils to test/lib/Utils which can be used in the
> closed part.
I've placed a couple of comments.
Otherwise, it looks okay to me.
1 - 100 of 130 matches
Mail list logo
