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
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:
>
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
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
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
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
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
> -
> 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
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
>>
>>
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
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
>>
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
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.
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
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 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
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
>
>
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
>> -
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
>>
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
>>
>>
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
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,
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
>>
>>
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
>>
>>
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
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
>>
>>
> 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
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
> -
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
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`
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
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
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
> 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
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
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
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
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
>>
42 matches
Mail list logo
