On Thu, 16 Nov 2023 12:35:08 GMT, Serguei Spitsyn wrote:
> This is an update for a performance/scalability enhancement.
>
> The `JvmtiVTMSTransitionDisabler`sync protocol is on a performance critical
> path of the virtual threads mount state transitions (VTMS transitions
On Thu, 30 Nov 2023 07:34:23 GMT, Serguei Spitsyn wrote:
>> This is an update for a performance/scalability enhancement.
>>
>> The `JvmtiVTMSTransitionDisabler`sync protocol is on a performance critical
>> path of the virtual threads mount state transitions (VTMS
On Thu, 30 Nov 2023 05:29:46 GMT, Chris Plummer wrote:
> That should in general take care of most unreachable virtual threads, but
> technically I don't think a virtual thread has to reach the TERMINATED state
> in order to become unreachable. However, it will never get scheduled.
Agreed.
On Thu, 30 Nov 2023 00:14:34 GMT, Patricio Chilano Mateo
wrote:
>> Serguei Spitsyn has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> review: make new fields volatile, use Atomic for access/update
>
On Wed, 29 Nov 2023 06:38:51 GMT, Stefan Karlsson wrote:
>> In the rewrites made for:
>> [JDK-8318757](https://bugs.openjdk.org/browse/JDK-8318757) `VM_ThreadDump
>> asserts in interleaved ObjectMonitor::deflate_monitor calls`
>>
>> I removed the filtering of *owned ObjectMonitors with dead
owse/JDK-8308614): Enabling JVMTI
> ClassLoad event slows down vthread creation by factor 10
>
> Testing:
> - Ran mach5 tiers 1-6 with no regressions noticed.
Serguei Spitsyn has updated the pull request incrementally with one additional
commit since the last revision:
review: addre
3251 ms
> - ClassLoad events are enabled: 40534 ms
>
> - With the fix:
> - no ClassLoad events enabled:3270 ms
> - ClassLoad events are enabled: 3385 ms
>
> Testing:
> - Ran mach5 tiers 1-6, no regressions are noticed
Serguei Spitsyn
On Wed, 29 Nov 2023 21:05:31 GMT, Daniel D. Daugherty
wrote:
>> Serguei Spitsyn has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> review: add comment for new ThreadsListHandle use
>
> I'm going to resurrec
On Thu, 30 Nov 2023 00:26:25 GMT, Alex Menkov wrote:
>> The change impelements dumping of unmounted virtual threads data (stack
>> traces and stack references).
>> Unmounted vthreads can be detected only by iterating over the heap, but
>> hprof stack trace records (HPROF_FRAME/HPROF_TRACE)
On Fri, 17 Nov 2023 10:30:59 GMT, Serguei Spitsyn wrote:
>> This is an update for a performance/scalability enhancement.
>>
>> The `JvmtiVTMSTransitionDisabler`sync protocol is on a performance critical
>> path of the virtual threads mount state transitions (VTMS
On Tue, 14 Nov 2023 21:54:06 GMT, Alex Menkov wrote:
> The change impelements dumping of unmounted virtual threads data (stack
> traces and stack references).
> Unmounted vthreads can be detected only by iterating over the heap, but hprof
> stack trace records (HPROF_FRAME/HPROF_TRACE) should
On Tue, 14 Nov 2023 21:54:06 GMT, Alex Menkov wrote:
> The change impelements dumping of unmounted virtual threads data (stack
> traces and stack references).
> Unmounted vthreads can be detected only by iterating over the heap, but hprof
> stack trace records (HPROF_FRAME/HPROF_TRACE) should
On Wed, 29 Nov 2023 20:51:02 GMT, Chris Plummer wrote:
>> The change impelements dumping of unmounted virtual threads data (stack
>> traces and stack references).
>> Unmounted vthreads can be detected only by iterating over the heap, but
>> hprof stack trace records (HPROF_FRAME/HPROF_TRACE)
On Wed, 29 Nov 2023 20:31:50 GMT, Chris Plummer wrote:
>> src/hotspot/share/services/heapDumper.cpp line 2026:
>>
>>> 2024: size_t buf_size = strlen(base_path)
>>> 2025: + 2 // ".p"
>>> 2026: + 1 + (seq / 10)// number
>>
>> Is
On Tue, 28 Nov 2023 22:40:10 GMT, Serguei Spitsyn wrote:
>> @jianglizhou Thank you for filing the sub-task. You have already seen some
>> crashes. Even though you do not have a standalone test case, it is still
>> valuable if you describe a test scenario (at least, surfa
On Tue, 28 Nov 2023 02:51:54 GMT, Serguei Spitsyn wrote:
>>> Thank you for filing and fixing this issue! I'm kind of late here. Sorry
>>> for that. Is it hard to create a JTreg test for an attaching native thread?
>>> I can help if you have a standalone proto
On Tue, 28 Nov 2023 18:36:00 GMT, Jiangli Zhou wrote:
>> This also was caught by my eyes. :)
>> With the lines 99-101 in place the only case when `thread_oop` can be equal
>> to `nullptr` is when `thread->threadObj() == nullptr`. My understanding is
>> that it can be for a detached thread
On Wed, 22 Nov 2023 22:40:20 GMT, Jiangli Zhou wrote:
>> Please review JvmtiThreadState::state_for_while_locked change to handle the
>> state->get_thread_oop() null case. Please see
>> https://bugs.openjdk.org/browse/JDK-8319935 for details.
>
> Jiangli Zhou has updated the pull request
On Mon, 13 Nov 2023 23:33:50 GMT, Man Cao wrote:
>> Jiangli Zhou has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Address Serguei Spitsyn's comments/suggestions:
>> - Remove the redundant thread->is_Java_thread() check from
>>
On Wed, 22 Nov 2023 23:58:54 GMT, Jiangli Zhou wrote:
>> Thank you for filing and fixing this issue! I'm kind of late here. Sorry
>> for that.
>> Is it hard to create a JTreg test for an attaching native thread? I can help
>> if you have a standalone prototype.
>> You can look for some
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, 27 Nov 2023 12:58:56 GMT, Stefan Karlsson wrote:
>> In the rewrites made for:
>> [JDK-8318757](https://bugs.openjdk.org/browse/JDK-8318757) `VM_ThreadDump
>> asserts in interleaved ObjectMonitor::deflate_monitor calls`
>>
>> I removed the filtering of *owned ObjectMonitors with dead
On Tue, 21 Nov 2023 13:01:55 GMT, Kevin Walls wrote:
> This test fails occasionally, and can be tuned to avoid most of the failures
> ever seen.
>
> It exists to check that notification work does not scale linearly with number
> of MBeans, so it calculates a ratio of the time taken with one,
On Mon, 27 Nov 2023 12:58:56 GMT, Stefan Karlsson wrote:
>> In the rewrites made for:
>> [JDK-8318757](https://bugs.openjdk.org/browse/JDK-8318757) `VM_ThreadDump
>> asserts in interleaved ObjectMonitor::deflate_monitor calls`
>>
>> I removed the filtering of *owned ObjectMonitors with dead
On Tue, 21 Nov 2023 02:58:47 GMT, Alex Menkov wrote:
>> FilteredFieldStream is intended to filter out some fields which does not
>> represent valid java objects.
>> Currently the only filtered field is "constantPoolOop" from
>> jdk.internal.reflect.ConstantPool class.
>> The change fixes
On Mon, 27 Nov 2023 09:44:23 GMT, Stefan Karlsson wrote:
>> test/hotspot/jtreg/serviceability/jvmti/GetOwnedMonitorInfo/GetOwnedMonitorInfoTest.java
>> line 53:
>>
>>> 51: private static native boolean hasEventPosted();
>>> 52:
>>> 53: private static void
On Mon, 27 Nov 2023 12:58:56 GMT, Stefan Karlsson wrote:
>> In the rewrites made for:
>> [JDK-8318757](https://bugs.openjdk.org/browse/JDK-8318757) `VM_ThreadDump
>> asserts in interleaved ObjectMonitor::deflate_monitor calls`
>>
>> I removed the filtering of *owned ObjectMonitors with dead
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, 20 Nov 2023 19:28:13 GMT, Jiangli Zhou wrote:
>> Please review JvmtiThreadState::state_for_while_locked change to handle the
>> state->get_thread_oop() null case. Please see
>> https://bugs.openjdk.org/browse/JDK-8319935 for details.
>
> Jiangli Zhou has updated the pull request
On Mon, 20 Nov 2023 19:28:13 GMT, Jiangli Zhou wrote:
>> Please review JvmtiThreadState::state_for_while_locked change to handle the
>> state->get_thread_oop() null case. Please see
>> https://bugs.openjdk.org/browse/JDK-8319935 for details.
>
> Jiangli Zhou has updated the pull request
On Mon, 20 Nov 2023 19:28:13 GMT, Jiangli Zhou wrote:
>> Please review JvmtiThreadState::state_for_while_locked change to handle the
>> state->get_thread_oop() null case. Please see
>> https://bugs.openjdk.org/browse/JDK-8319935 for details.
>
> Jiangli Zhou has updated the pull request
On Mon, 20 Nov 2023 00:59:35 GMT, David Holmes wrote:
>> @dcubed-ojdk
>> I don't know FJP implementation well enough to point at the code where it
>> happens. However, I observe that new `JavaThread `is being created between
>> two points of the execution path.
>> - First point is in the
On Wed, 1 Nov 2023 18:44:04 GMT, Serguei Spitsyn wrote:
> The handshakes support for virtual threads is needed to simplify the JVMTI
> implementation for virtual threads. There is a significant duplication in the
> JVMTI code to differentiate code intended to support platform
On Sun, 19 Nov 2023 05:12:50 GMT, Serguei Spitsyn wrote:
>> The handshakes support for virtual threads is needed to simplify the JVMTI
>> implementation for virtual threads. There is a significant duplication in
>> the JVMTI code to differentiate code intended to support
On Mon, 20 Nov 2023 00:59:35 GMT, David Holmes wrote:
>> The stack trace of current thread (where the assert was fired) can explain
>> what is going on a little bit:
>>
>> Current thread (0x7f93f8043d00): JavaThread "ForkJoinPool-1-worker-1"
>> daemon [_thread_in_vm, id=16779,
>>
On Sun, 19 Nov 2023 09:22:43 GMT, Serguei Spitsyn wrote:
>> @sspitsyn - Please point me at the code where these JavaThreads are newly
>> created?
>
> @dcubed-ojdk
> I don't know FJP implementation well enough to point at the code where it
> happens. However, I obse
On Sun, 19 Nov 2023 03:47:45 GMT, Daniel D. Daugherty
wrote:
>> Thank you for the comment, Dan!
>> Agreed, the comment needs to be corrected in two aspects.
>> I tried to simplify it but failed to do it correctly.
>> It is interesting that there is a `ThreadsListHandle` farther up the stack
>>
On Sat, 18 Nov 2023 14:35:58 GMT, Serguei Spitsyn wrote:
>> src/hotspot/share/prims/jvmtiEnvBase.cpp line 631:
>>
>>> 629: return !jdk_internal_vm_Continuation::done(cont) &&
>>> 630: java_lang_VirtualThread::state(vt) !=
>&
failed with "check_jvmti_status: JVMTI
> function returned error: JVMTI_ERROR_THREAD_NOT_ALIVE (15)"
>
> Testing:
> - the mach5 tiers 1-6 are all passed
Serguei Spitsyn has updated the pull request incrementally with one additional
commit since the last revision:
review: remove j
failed with "check_jvmti_status: JVMTI
> function returned error: JVMTI_ERROR_THREAD_NOT_ALIVE (15)"
>
> Testing:
> - the mach5 tiers 1-6 are all passed
Serguei Spitsyn has updated the pull request incrementally with one additional
commit since the last revision:
review
On Sat, 18 Nov 2023 01:37:21 GMT, Alex Menkov wrote:
>> Serguei Spitsyn has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> review: add jdk_internal_vm_Continuation::done(cont) check to
>> JvmtiEnvBase::is
On Sat, 18 Nov 2023 02:29:26 GMT, Alex Menkov wrote:
>> Serguei Spitsyn has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> review: add jdk_internal_vm_Continuation::done(cont) check to
>> JvmtiEnvBase::is
On Fri, 17 Nov 2023 21:19:05 GMT, Daniel D. Daugherty
wrote:
>> Serguei Spitsyn has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> review: add comment for new ThreadsListHandle use
>
> src/hotspot/share/prims
On Fri, 17 Nov 2023 18:52:20 GMT, Chris Plummer wrote:
>> The `tlh` is used to protect any existing at this point JavaThread's from
>> being terminated while it is set.
>> My understanding is that there is no need to iterate over all threads in the
>> list to get this protection.
>
> Ok. A
3251 ms
> - ClassLoad events are enabled: 40534 ms
>
> - With the fix:
> - no ClassLoad events enabled:3270 ms
> - ClassLoad events are enabled: 3385 ms
>
> Testing:
> - Ran mach5 tiers 1-6, no regressions are noticed
Serguei Spitsyn has updated the
owse/JDK-8308614): Enabling JVMTI
> ClassLoad event slows down vthread creation by factor 10
>
> Testing:
> - Ran mach5 tiers 1-6 with no regressions noticed.
Serguei Spitsyn has updated the pull request incrementally with one additional
commit since the last revision:
review: make new
3251 ms
> - ClassLoad events are enabled: 40534 ms
>
> - With the fix:
> - no ClassLoad events enabled:3270 ms
> - ClassLoad events are enabled: 3385 ms
>
> Testing:
> - Ran mach5 tiers 1-6, no regressions are noticed
Serguei Spitsyn has updated th
On Fri, 17 Nov 2023 05:43:21 GMT, Serguei Spitsyn wrote:
>> src/hotspot/share/prims/jvmtiThreadState.cpp line 531:
>>
>>> 529:
>>> 530: // JvmtiThreadState objects for virtual thread filtered events
>>> enabled globally
>>> 531: //
On Fri, 17 Nov 2023 05:55:44 GMT, Chris Plummer wrote:
>> This is explained in the PR description.
>> Do you think, a just comment is needed or this has to be separated from this
>> fix?
>
> I see the PR comment, but I don't really understand it. Is this to force some
> sort of early
On Thu, 16 Nov 2023 21:36:28 GMT, Chris Plummer wrote:
>> This is a fix of a performance/scalability related issue. The
>> `JvmtiThreadState` objects for virtual thread filtered events enabled
>> globally are created eagerly because it is needed when the
>> `interp_only_mode` is enabled.
failed with "check_jvmti_status: JVMTI
> function returned error: JVMTI_ERROR_THREAD_NOT_ALIVE (15)"
>
> Testing:
> - the mach5 tiers 1-6 are all passed
Serguei Spitsyn has updated the pull request incrementally with one additional
commit since the last revision:
revie
On Fri, 17 Nov 2023 02:10:50 GMT, Patricio Chilano Mateo
wrote:
>> If it is a part of the `JvmtiEnvBase::is_vthread_alive()` then it is racy
>> for mounted virtual threads.
>> It is not racy for unmounted virtual threads.
>
> So we should only see that a continuation is done for an unmounted
On Thu, 16 Nov 2023 19:02:39 GMT, Patricio Chilano Mateo
wrote:
>> I'm suggesting to fix it this way for the unmounted case only:
>>
>> @@ -1976,6 +1976,13 @@ JvmtiHandshake::execute(JvmtiUnitedHandshakeClosure*
>> hs_cl, ThreadsListHandle* t
>>return;
>> }
>> if (target_jt
On Thu, 16 Nov 2023 17:05:17 GMT, Leonid Mesnik wrote:
>> This is an update for a performance/scalability enhancement.
>>
>> The `JvmtiVTMSTransitionDisabler`sync protocol is on a performance critical
>> path of the virtual threads mount state transitions (VTMS transitions). It
>> has a
On Wed, 8 Nov 2023 16:02:08 GMT, Serguei Spitsyn wrote:
>> src/hotspot/share/prims/jvmtiEnvBase.cpp line 2416:
>>
>>> 2414: if (!JvmtiEnvBase::is_vthread_alive(_target_h())) {
>>> 2415: return; // JVMTI_ERROR_THREAD_NOT_ALIVE (default)
>>> 2416: }
On Thu, 16 Nov 2023 16:27:23 GMT, Serguei Spitsyn wrote:
>> So the problematic case I'm thinking is when the JvmtiVTMSTransitionDisabler
>> starts after the vthread executed notifyJvmtiUnmount(), i.e the vthread is
>> already outside the transition, but before changing the s
On Thu, 16 Nov 2023 15:20:31 GMT, Patricio Chilano Mateo
wrote:
>> I've added the check for `!jdk_internal_vm_Continuation::done(cont)` into `
>> JvmtiEnvBase::is_vthread_alive(oop vt)` but then decided to remove it again.
>> This is racy for `JvmtiHandshake` execution. As you correctly
> It is a fix of a minor test issue.
> The test should not fail when the JVMTI function `SetEventNotificationMode()`
> returns errors codes:
> - `JVMTI_ERROR_THREAD_NOT_ALIVE`
> - `JVMTI_ERROR_WRONG_PHASE`
>
> Tested the fix locally and with mach5 test runs.
Serguei Spitsyn
This is an update for a performance/scalability enhancement.
The `JvmtiVTMSTransitionDisabler`sync protocol is on a performance critical
path of the virtual threads mount state transitions (VTMS transitions). It has
a noticeable performance overhead (about 10%) which contributes to the combined
This is a fix of a performance/scalability related issue. The
`JvmtiThreadState` objects for virtual thread filtered events enabled globally
are created eagerly because it is needed when the `interp_only_mode` is
enabled. Otherwise, some events which are generated in `interp_only_mode` from
failed with "check_jvmti_status: JVMTI
> function returned error: JVMTI_ERROR_THREAD_NOT_ALIVE (15)"
>
> Testing:
> - the mach5 tiers 1-6 are all passed
Serguei Spitsyn has updated the pull request with a new target base due to a
merge or a rebase. The incremental webrev exclude
On Wed, 8 Nov 2023 16:11:44 GMT, Serguei Spitsyn wrote:
>> src/hotspot/share/prims/jvmtiEnvBase.cpp line 1974:
>>
>>> 1972:
>>> 1973: if (java_lang_VirtualThread::is_instance(target_h())) { // virtual
>>> thread
>>> 1974:
failed with "check_jvmti_status: JVMTI
> function returned error: JVMTI_ERROR_THREAD_NOT_ALIVE (15)"
>
> Testing:
> - the mach5 tiers 1-6 are all passed
Serguei Spitsyn has updated the pull request incrementally with one additional
commit since the last revision:
addressed revi
failed with "check_jvmti_status: JVMTI
> function returned error: JVMTI_ERROR_THREAD_NOT_ALIVE (15)"
>
> Testing:
> - the mach5 tiers 1-6 are all passed
Serguei Spitsyn has updated the pull request incrementally with one additional
commit since the last revision:
addressed review: a
On Tue, 7 Nov 2023 14:44:52 GMT, Patricio Chilano Mateo
wrote:
>> Serguei Spitsyn has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> review: get rid of the VM_HandshakeUnmountedVirtualThread
>
> src/hotspo
On Tue, 7 Nov 2023 14:23:34 GMT, Patricio Chilano Mateo
wrote:
>> Serguei Spitsyn has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> review: get rid of the VM_HandshakeUnmountedVirtualThread
>
> src/hotspo
On Tue, 7 Nov 2023 14:54:05 GMT, Patricio Chilano Mateo
wrote:
> Hi Serguei,
> Looks good to me, nice code consolidation.
Hi Patricio, thank you a lot for reviewing this!
> src/hotspot/share/prims/jvmtiEnvBase.cpp line 1978:
>
>> 1976: }
>> 1977: if (target_jt == nullptr) {//
On Mon, 6 Nov 2023 23:22:03 GMT, Serguei Spitsyn wrote:
>> The handshakes support for virtual threads is needed to simplify the JVMTI
>> implementation for virtual threads. There is a significant duplication in
>> the JVMTI code to differentiate code intended to support
kTraceSuspendedStressTest.java failed with "check_jvmti_status: JVMTI
> function returned error: JVMTI_ERROR_THREAD_NOT_ALIVE (15)"
>
> Testing:
> - the mach5 tiers 1-6 are all passed
Serguei Spitsyn has updated the pull request incrementally with one additional
c
On Mon, 6 Nov 2023 20:04:44 GMT, Serguei Spitsyn wrote:
>> Is the issue here that agent thread started by Debuggee.checkStatus is
>> racing with the test? The producer/consumer thread do 1000 put/take ops and
>> it looks like it can complete and VM commence shutdown while th
On Mon, 6 Nov 2023 06:16:20 GMT, Alan Bateman wrote:
>> My question exactly. I'm not even sure why wrong phase is allowed here.
>
> Is the issue here that agent thread started by Debuggee.checkStatus is racing
> with the test? The producer/consumer thread do 1000 put/take ops and it looks
>
It is a fix of a minor test issue.
The test should not fail when the JVMTI function `SetEventNotificationMode()`
returns errors codes:
- `JVMTI_ERROR_THREAD_NOT_ALIVE`
- `JVMTI_ERROR_WRONG_PHASE`
Tested the fix locally and with mach5 test runs.
-
Commit messages:
- 8318631:
On Thu, 2 Nov 2023 18:16:49 GMT, Kevin Walls wrote:
>> test/jdk/javax/management/monitor/ThreadPoolAccTest.java line 167:
>>
>>> 165: String expected = principals[i / 3];
>>> 166:
>>> 167: echo("testPrincipals: monitored: " + monitored[i] + "
>>> principal: " +
kTraceSuspendedStressTest.java failed with "check_jvmti_status: JVMTI
> function returned error: JVMTI_ERROR_THREAD_NOT_ALIVE (15)"
>
> Testing:
> - the mach5 tiers 1-6 are all passed
Serguei Spitsyn has updated the pull request incrementally with one additiona
kTraceSuspendedStressTest.java failed with "check_jvmti_status: JVMTI
> function returned error: JVMTI_ERROR_THREAD_NOT_ALIVE (15)"
>
> Testing:
> - the mach5 tiers 1-6 are all passed
Serguei Spitsyn has updated the pull request incrementally with two additional
commits sin
On Wed, 1 Nov 2023 17:10:34 GMT, Kevin Walls wrote:
> Discovered while testing changes that made this test fail. The test failure
> is hard to diagnose as it logs and retries at full speed, possibly forever,
> until timeout. This can hit a log file limit. We can save thousands of
> lines
The handshakes support for virtual threads is needed to simplify the JVMTI
implementation for virtual threads. There is a significant duplication in the
JVMTI code to differentiate code intended to support platform, virtual threads
or both. The handshakes are unified, so it is enough to define
On Thu, 19 Oct 2023 07:54:47 GMT, Kimura Yukihiro wrote:
>> I would like to fix this issue
>> because the test dose not work as intended.
>> Could someone please review it?
>>
>> Thanks,
>> Kimura Yukihiro
>
> Kimura Yukihiro has updated the pull request incrementally with one
> additional
On Thu, 19 Oct 2023 07:54:47 GMT, Kimura Yukihiro wrote:
>> I would like to fix this issue
>> because the test dose not work as intended.
>> Could someone please review it?
>>
>> Thanks,
>> Kimura Yukihiro
>
> Kimura Yukihiro has updated the pull request incrementally with one
> additional
On Mon, 30 Oct 2023 09:28:03 GMT, Kimura Yukihiro wrote:
> This project has not yet received a notification from the bot that I can type
> the integrate command. Should I adde a noreg-self label on JBS, or should I
> find one more reviewer?
>
> Thanks, Kimura Yukihiro
You can see this
On Tue, 24 Oct 2023 00:46:54 GMT, Alex Menkov wrote:
> FilteredFieldStream is intended to filter out some fields which does not
> represent valid java objects.
> Currently the only filtered field is "constantPoolOop" from
> jdk.internal.reflect.ConstantPool class.
> The change fixes
On Mon, 23 Oct 2023 00:00:47 GMT, Kimura Yukihiro wrote:
> Hi Serguei,
>
> Thank you for your quick reply. Could you please sponsor the fix?
>
> Thanks, Kimura Yukihiro
I was hoping to have one more reviewer of your fix.
But it seems there is nobody else to review it.
Sponsored now.
On Fri, 20 Oct 2023 13:28:19 GMT, Kevin Walls wrote:
>> From studying test failures, it looks like the way the test identifies its
>> related processes is failing.
>> It checks the mainArgs of a process by attaching, and looks like it
>> occasionally misses getting a valid match. The
On Fri, 20 Oct 2023 03:20:44 GMT, Leonid Mesnik wrote:
> There are several failure with reason
> "Cannot invoke "String.equals(Object)" because "" is null"
> which really caused by reading the command from debugee via socket.
> Like:
>
> String command = pipe.readln();
>
> if
On Thu, 19 Oct 2023 05:56:53 GMT, Ioi Lam wrote:
> This is the first step for [JDK-8318483 - Move CDS configuration management
> into cdsConfig.hpp](https://bugs.openjdk.org/browse/JDK-8318483)
>
> - Remove `Arguments::is_dumping_archive()` and `Arguments
> assert_is_dumping_archive()`
> -
On Thu, 19 Oct 2023 09:33:49 GMT, Alan Bateman wrote:
>> JVMTI is notified after a virtual thread unmounts. Right not, this
>> notification is done after the virtual thread has finished parking or
>> yielding so it's possible for the virtual to continue, and be mounted on a
>> different
On Thu, 19 Oct 2023 07:54:47 GMT, Kimura Yukihiro wrote:
>> I would like to fix this issue
>> because the test dose not work as intended.
>> Could someone please review it?
>>
>> Thanks,
>> Kimura Yukihiro
>
> Kimura Yukihiro has updated the pull request incrementally with one
> additional
On Wed, 18 Oct 2023 07:34:19 GMT, Kimura Yukihiro wrote:
> I would like to fix this issue
> because the test dose not work as intended.
> Could someone please review it?
>
> Thanks,
> Kimura Yukihiro
Hi Kimura,
The fix looks okay to me. Thank you for taking care about it.
I'm not aware much
On Thu, 19 Oct 2023 02:19:35 GMT, Alex Menkov wrote:
>> All test cases in getclfld007 had 1 (or 0) field in test classes/interfaces.
>> The change adds several fields in one of the test classes to verify order of
>> the returned fields (as described by GetClassFields spec: "in the order they
On Wed, 18 Oct 2023 01:40:18 GMT, Alex Menkov wrote:
>> All test cases in getclfld007 had 1 (or 0) field in test classes/interfaces.
>> The change adds several fields in one of the test classes to verify order of
>> the returned fields (as described by GetClassFields spec: "in the order they
On Wed, 18 Oct 2023 01:40:18 GMT, Alex Menkov wrote:
>> All test cases in getclfld007 had 1 (or 0) field in test classes/interfaces.
>> The change adds several fields in one of the test classes to verify order of
>> the returned fields (as described by GetClassFields spec: "in the order they
On Wed, 18 Oct 2023 01:40:18 GMT, Alex Menkov wrote:
>> All test cases in getclfld007 had 1 (or 0) field in test classes/interfaces.
>> The change adds several fields in one of the test classes to verify order of
>> the returned fields (as described by GetClassFields spec: "in the order they
On Wed, 18 Oct 2023 01:40:18 GMT, Alex Menkov wrote:
>> All test cases in getclfld007 had 1 (or 0) field in test classes/interfaces.
>> The change adds several fields in one of the test classes to verify order of
>> the returned fields (as described by GetClassFields spec: "in the order they
On Wed, 18 Oct 2023 21:48:33 GMT, Johannes Bechberger
wrote:
>> Fix `onthrow` issue by passing the event info to the `initialize` method.
>>
>> This prevents `jdb` from receiving a broken exception event and throwing an
>> internal NullPointerException, upon attaching to the JDWP-agent.
>
>
On Sat, 14 Oct 2023 18:07:45 GMT, Alan Bateman wrote:
> JVMTI is notified after a virtual thread unmounts. Right not, this
> notification is done after the virtual thread has finished parking or
> yielding so it's possible for the virtual to continue, and be mounted on a
> different carrier,
On Fri, 13 Oct 2023 01:15:58 GMT, Alex Menkov wrote:
> The change fixes misspelled "referer" in test/lib/jdk/test/lib/hprof library
> The only caller of changed public API is VThreadInHeapDump.java
Looks good.
Thanks,
serguei
-
Marked as reviewed by sspitsyn (Reviewer).
PR
On Tue, 10 Oct 2023 20:34:44 GMT, Leonid Mesnik wrote:
>> 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
>>
On Mon, 2 Oct 2023 23:11:01 GMT, Serguei Spitsyn wrote:
> The JVMTI VirtualThreadStart events have to follow the ThreadStart events
> pattern and so, should not be thread-filtered.
> The fix includes:
> - `jvmti.xml`: remov the attribute `filtered="thread"` in the
On Tue, 10 Oct 2023 02:44:53 GMT, Chris Plummer wrote:
>> A JavaThread can be hidden, not a virtual thread.
>> For such a case, I'd treat it that a carrier thread is hidden.
>> The assert is to catch if it ever happens.
>> Do you think this assert is an overkill?
>
> Never mind. I see you
On Tue, 10 Oct 2023 00:54:42 GMT, Serguei Spitsyn wrote:
>> The JVMTI VirtualThreadStart events have to follow the ThreadStart events
>> pattern and so, should not be thread-filtered.
>> The fix includes:
>> - `jvmti.xml`: remov the attribute `filtered="thread"
501 - 600 of 1579 matches
Mail list logo
