On Mon, 4 Dec 2023 23:47:12 GMT, David Holmes wrote:
>> Please review this simple clarification to the JVM TI spec regarding use of
>> `JAVA_TOOL_OPTIONS` in regards to module options and their format.
>>
>> I do not believe this clarification needs a CSR request.
>>
>> Thanks.
>
> David Holme
On Tue, 5 Dec 2023 00:23:45 GMT, Serguei Spitsyn wrote:
> The fix is for a regression caused by:
> [8308614](https://bugs.openjdk.org/browse/JDK-8308614) Enabling JVMTI
> ClassLoad event slows down vthread creation by factor 10
>
> The fix of 8308614 just triggered a known issue:
> [8316283]
On Tue, 5 Dec 2023 01:20:28 GMT, Alex Menkov wrote:
> VM_HeapDumper caches stack traces for platform/carrier and mounted virtual
> threads only.
> For unmounted virtual threads ThreadDumper objects are created on the stack
> (see `VM_HeapDumper::dump_vthread`), so I don't see problems with memo
On Mon, 4 Dec 2023 19:14:59 GMT, Chris Plummer wrote:
> > My understanding that information about references is one of the most
> > important things for dump analysis (and that's what the issue about). So we
> > cannot avoid stack unwinding for unmounted virtual threads.
> > As for heapdump fil
On Fri, 24 Nov 2023 06:06:16 GMT, Jaikiran Pai wrote:
> Can I please get a review of this change which proposes to fix the issue
> noted in https://bugs.openjdk.org/browse/JDK-8320687?
>
> As noted in the issue, the
> `sun.jvmstat.monitor.MonitoredHost.getMonitoredHost()` uses a shared instanc
On Fri, 24 Nov 2023 13:00:33 GMT, Jaikiran Pai wrote:
>> Can I please get a review of this change which proposes to fix the issue
>> noted in https://bugs.openjdk.org/browse/JDK-8320687?
>>
>> As noted in the issue, the
>> `sun.jvmstat.monitor.MonitoredHost.getMonitoredHost()` uses a shared
>
On Mon, 4 Dec 2023 23:47:12 GMT, David Holmes wrote:
>> Please review this simple clarification to the JVM TI spec regarding use of
>> `JAVA_TOOL_OPTIONS` in regards to module options and their format.
>>
>> I do not believe this clarification needs a CSR request.
>>
>> Thanks.
>
> David Holme
The fix is for a regression caused by:
[8308614](https://bugs.openjdk.org/browse/JDK-8308614) Enabling JVMTI
ClassLoad event slows down vthread creation by factor 10
The fix of 8308614 just triggered a known issue:
[8316283](https://bugs.openjdk.org/browse/JDK-8316283) field watch events are
On Sat, 2 Dec 2023 07:37:26 GMT, Jonathan Joo wrote:
>> 8315149: Add hsperf counters for CPU time of internal GC threads
>
> Jonathan Joo has updated the pull request incrementally with two additional
> commits since the last revision:
>
> - Only create CPUTimeCounters if supported
> - Ensure
> Please review this simple clarification to the JVM TI spec regarding use of
> `JAVA_TOOL_OPTIONS` in regards to module options and their format.
>
> I do not believe this clarification needs a CSR request.
>
> Thanks.
David Holmes has updated the pull request incrementally with one additional
On Mon, 4 Dec 2023 18:16:52 GMT, Daniel D. Daugherty wrote:
>> In the fix for the following bug:
>>
>> [JDK-8319935](https://bugs.openjdk.org/browse/JDK-8319935) Ensure only one
>> JvmtiThreadState is created for one JavaThread associated with attached
>> native thread
>>
>> JvmtiThreadState:
On Mon, 4 Dec 2023 12:35:42 GMT, Alan Bateman wrote:
>> Thanks for looking at this @AlanBateman and @sspitsyn . I was trying to
>> refer to the JNI text in a casual way rather than duplicating the actual
>> content from there. This was more a strong hint/suggestion to "go read the
>> JNI spec
On Mon, 4 Dec 2023 13:07:15 GMT, Stefan Johansson wrote:
>> In the interest of the RDP1 deadline, should we leave improving the sync
>> issues with gc_total to a separate RFE? (Especially given that a "correct"
>> design may take some time to come up with, and that gc_total being slightly
>> o
On Wed, 29 Nov 2023 11:49:31 GMT, Jaroslav Bachorik
wrote:
>> Please, review this fix for a corner case handling of `jmethodID` values.
>>
>> The issue is related to the interplay between `jmethodID` values and method
>> redefinitions. Each `jmethodID` value is effectively a pointer to a `Meth
On Mon, 4 Dec 2023 20:52:46 GMT, Daniel D. Daugherty wrote:
> In the interest of reducing the noise in the Mach5 CI, I'm going ahead with
> integrating this fix without waiting for a reply to my comment above. If
> there are remaining issues, then we'll deal with them in a follow-up bug/RFE.
T
On Mon, 4 Dec 2023 20:52:46 GMT, Daniel D. Daugherty wrote:
>>> @jianglizhou - Thanks for doing the testing. Can you also do a review? We
>>> need two reviewers for this change.
>>
>> Complete test run finished. Checking the results, looks like there's no
>> issue related to JVMTIThreadState c
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 in
On Fri, 1 Dec 2023 07:59:49 GMT, Jaikiran Pai wrote:
> I'm looking for one more Reviewer, please.
You have 2 reviewers already.
-
PR Comment: https://git.openjdk.org/jdk/pull/16805#issuecomment-1839539742
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 in
On Sat, 2 Dec 2023 17:15:57 GMT, Daniel D. Daugherty wrote:
> In the fix for the following bug:
>
> [JDK-8319935](https://bugs.openjdk.org/browse/JDK-8319935) Ensure only one
> JvmtiThreadState is created for one JavaThread associated with attached
> native thread
>
> JvmtiThreadState::state_
On Mon, 4 Dec 2023 19:01:05 GMT, Jiangli Zhou wrote:
>> @dcubed-ojdk Thanks for the notification. I just ran one of our affected
>> test 100 times with JDK-8312174 change rolled back and with both following
>> applied:
>>
>> - https://git.openjdk.org/jdk/pull/16642
>> - https://github.com/open
On Mon, 4 Dec 2023 18:13:50 GMT, Daniel D. Daugherty wrote:
>> Initially I thought this was not the right fix as we should not be exposing
>> an attaching thread that may still have a partially constructed `threadObj`.
>> But this issue shows that we must expose such a thread because the
>> co
On Mon, 4 Dec 2023 18:16:52 GMT, Daniel D. Daugherty wrote:
>> In the fix for the following bug:
>>
>> [JDK-8319935](https://bugs.openjdk.org/browse/JDK-8319935) Ensure only one
>> JvmtiThreadState is created for one JavaThread associated with attached
>> native thread
>>
>> JvmtiThreadState:
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 internal "RUNNABLE" state is replaced
with UNPARKED and YIELDED st
On Sat, 2 Dec 2023 01:48:28 GMT, Alex Menkov wrote:
> My understanding that information about references is one of the most
> important things for dump analysis (and that's what the issue about). So we
> cannot avoid stack unwinding for unmounted virtual threads.
> As for heapdump file size, ea
On Mon, 4 Dec 2023 18:16:52 GMT, Daniel D. Daugherty wrote:
>> In the fix for the following bug:
>>
>> [JDK-8319935](https://bugs.openjdk.org/browse/JDK-8319935) Ensure only one
>> JvmtiThreadState is created for one JavaThread associated with attached
>> native thread
>>
>> JvmtiThreadState:
On Mon, 4 Dec 2023 05:16:59 GMT, Jiangli Zhou wrote:
>> In the fix for the following bug:
>>
>> [JDK-8319935](https://bugs.openjdk.org/browse/JDK-8319935) Ensure only one
>> JvmtiThreadState is created for one JavaThread associated with attached
>> native thread
>>
>> JvmtiThreadState::state_
On 12/4/23 5:20 AM, Alan Bateman wrote:
On 04/12/2023 12:41, David Holmes wrote:
On 1/12/2023 2:08 pm, Alex Menkov wrote:
On Thu, 30 Nov 2023 21:11:08 GMT, Chris Plummer
wrote:
I wasn't thinking in terms of the scheduler somehow no longer
references the virtual thread, but instead the pr
On Mon, 4 Dec 2023 06:31:43 GMT, David Holmes wrote:
>> Daniel D. Daugherty has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> dholmes CR - adjust a comment.
>
> Initially I thought this was not the right fix as we should not be exposing
>
On Mon, 4 Dec 2023 05:16:59 GMT, Jiangli Zhou wrote:
>> In the fix for the following bug:
>>
>> [JDK-8319935](https://bugs.openjdk.org/browse/JDK-8319935) Ensure only one
>> JvmtiThreadState is created for one JavaThread associated with attached
>> native thread
>>
>> JvmtiThreadState::state_
> In the fix for the following bug:
>
> [JDK-8319935](https://bugs.openjdk.org/browse/JDK-8319935) Ensure only one
> JvmtiThreadState is created for one JavaThread associated with attached
> native thread
>
> JvmtiThreadState::state_for_while_locked() was changed to
> return nullptr for attachi
On Sat, 2 Dec 2023 07:37:26 GMT, Jonathan Joo wrote:
>> 8315149: Add hsperf counters for CPU time of internal GC threads
>
> Jonathan Joo has updated the pull request incrementally with two additional
> commits since the last revision:
>
> - Only create CPUTimeCounters if supported
> - Ensure
On 04/12/2023 12:41, David Holmes wrote:
On 1/12/2023 2:08 pm, Alex Menkov wrote:
On Thu, 30 Nov 2023 21:11:08 GMT, Chris Plummer
wrote:
I wasn't thinking in terms of the scheduler somehow no longer
references the virtual thread, but instead the program no longer
referencing the scheduler
On Fri, 1 Dec 2023 22:37:58 GMT, Jonathan Joo wrote:
>> I think the ideal approach to simplify this is to support Atomic operation
>> on a `PerfCounter`.
>> We could either introduce a `PerfAtomicCounter`/`PerfAtomicLongCounter`
>> class, or perform `Atomic::add()` on the `PerfData::_valuep` po
On 1/12/2023 2:08 pm, Alex Menkov wrote:
On Thu, 30 Nov 2023 21:11:08 GMT, Chris Plummer wrote:
I wasn't thinking in terms of the scheduler somehow no longer references the
virtual thread, but instead the program no longer referencing the scheduler
(and also not referencing the virtual threa
On Mon, 4 Dec 2023 04:43:46 GMT, David Holmes wrote:
>> src/hotspot/share/prims/jvmti.xml line 746:
>>
>>> 744: JNI_CreateJavaVM (in the JNI Invocation API) will
>>> prepend these options to the options supplied
>>> 745: in its JavaVMInitArgs argument. Note that module
>>> related opti
On Mon, 4 Dec 2023 11:11:27 GMT, Thomas Stuefe wrote:
> Okay so why does this happen and is it a reasonable thing to be happening? On
> the surface it sounds wrong to deallocate anything associated with a live
> classloader.
If we didn't deallocate these old methods, there would be a memory le
> On AIX, repeated calls to dlopen referring to the same shared library may
> result in different, unique dl handles to be returned from libc. In that it
> differs from typical libc implementations that cache dl handles.
>
> This causes problems in the JVM with code that assumes equality of hand
On Wed, 29 Nov 2023 11:49:31 GMT, Jaroslav Bachorik
wrote:
>> Please, review this fix for a corner case handling of `jmethodID` values.
>>
>> The issue is related to the interplay between `jmethodID` values and method
>> redefinitions. Each `jmethodID` value is effectively a pointer to a `Meth
On Mon, 4 Dec 2023 00:41:23 GMT, David Holmes wrote:
> From the blog:
>
> > Yes! The methods are being deallocated for a class loader that is still
> > alive.
>
> Okay so why does this happen and is it a reasonable thing to be happening? On
> the surface it sounds wrong to deallocate anything
On Fri, 1 Dec 2023 05:15:15 GMT, Thomas Stuefe wrote:
>> Jaroslav Bachorik has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Restrict cleanup to obsolete methods only
>
> I won't be able to review this this week, too snowed in atm. I can t
On Sat, 2 Dec 2023 01:22:33 GMT, Jonathan Joo wrote:
>> I still think that a total counter is useful and I'd appreciate if you can
>> keep it. To second what @caoman said before, it is GC agnostic, easy to use
>> even for non GC experts and future proof with regards to implementation
>> change
42 matches
Mail list logo