On Tue, 11 Jun 2024 18:07:10 GMT, Robert Toyonaga wrote:
>> ### Summary
>> This change ensures we don't get undefined behavior when
>> calling[`isspace`](https://pubs.opengroup.org/onlinepubs/007904975/functions/isspace.html).
>> `isspace` accepts an `int` argument that "the application shall
On Tue, 11 Jun 2024 21:05:38 GMT, Inigo Mediavilla Saiz
wrote:
>> Print the stack traces of mounted virtual threads when calling `jcmd
>> Thread.print`.
>
> Inigo Mediavilla Saiz has updated the pull request incrementally with one
> additional commit since the last revision:
>
> Require
On Mon, 10 Jun 2024 13:36:06 GMT, Robert Toyonaga wrote:
> But what about when an int is passed to isspace?
The current casts to int are incorrect as a negative value would be
sign-extended and then fail the range check. I think we have to cast to
unsigned char in all cases in the caller,
On Mon, 10 Jun 2024 02:31:00 GMT, David Holmes wrote:
> Sets the version to 24/24-ea and the copyright year to 2025.
>
> Content changes related to the start of release (e.g. for removed options in
> java.1) are handled separately.
>
> This initial generation also picks
On Mon, 10 Jun 2024 17:27:18 GMT, Iris Clark wrote:
>> David Holmes has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Regenerated after merge
>
> Marked as reviewed by iris (Reviewer).
Thanks for the re
-8330807: Update Manpage for obsoletion of ScavengeBeforeFullGC
> - JDK-8284500: Typo in Supported Named Extensions - BasicContraints
> - JDK-8324342: Doclet should default `@since` for a nested class to that of
> its enclosing class
>
> Thanks
David Holmes has updated the pull request in
-8330807: Update Manpage for obsoletion of ScavengeBeforeFullGC
> - JDK-8284500: Typo in Supported Named Extensions - BasicContraints
> - JDK-8324342: Doclet should default `@since` for a nested class to that of
> its enclosing class
>
> Thanks
David Holmes has updated the pull reques
On Fri, 7 Jun 2024 06:07:17 GMT, Thomas Stuefe wrote:
> "To use these functions safely with plain chars (or signed chars), the
> argument should first be converted to unsigned char"
@tstuefe wow! Okay. That is a surprise to me. A cast to unsigned char doesn't
actually do anything. Every char
On Mon, 10 Jun 2024 07:15:51 GMT, Alan Bateman wrote:
>> Sets the version to 24/24-ea and the copyright year to 2025.
>>
>> Content changes related to the start of release (e.g. for removed options in
>> java.1) are handled separately.
>>
>> This initial generation also picks up the
On Fri, 7 Jun 2024 10:40:07 GMT, Thomas Stuefe wrote:
> @dholmes-ora this is one of yours.
>
> This was a tad annoying to fix (fix is simple though), since the jcmd
> framework has no good way to allow for default parameters that are not used
> literally. E.g. in this case, the real value for
Sets the version to 24/24-ea and the copyright year to 2025.
Content changes related to the start of release (e.g. for removed options in
java.1) are handled separately.
This initial generation also picks up the unpublished changes from:
- JDK-8330807: Update Manpage for obsoletion of
On Fri, 7 Jun 2024 19:56:03 GMT, Chris Plummer wrote:
> Allow warning messages such as the following to appear in stderr:
>
> Java HotSpot(TM) 64-Bit Server VM warning: Temporarily processing option
> UseNotificationThread; support is scheduled for removal in 24.0
>
> Tested by running CI
On Fri, 7 Jun 2024 19:56:03 GMT, Chris Plummer wrote:
> Allow warning messages such as the following to appear in stderr:
>
> Java HotSpot(TM) 64-Bit Server VM warning: Temporarily processing option
> UseNotificationThread; support is scheduled for removal in 24.0
>
> Tested by running CI
On Wed, 5 Jun 2024 20:08:10 GMT, Robert Toyonaga wrote:
> ### Summary
> This change ensures we don't get undefined behavior when
> calling[`isspace`](https://pubs.opengroup.org/onlinepubs/007904975/functions/isspace.html).
> `isspace` accepts an `int` argument that "the application shall
On Tue, 4 Jun 2024 07:25:41 GMT, Inigo Mediavilla Saiz wrote:
>> Print the stack traces of mounted virtual threads when calling `jcmd
>> Thread.print`.
>
> Inigo Mediavilla Saiz has updated the pull request incrementally with two
> additional commits since the last revision:
>
> - Cleanup
On Mon, 3 Jun 2024 13:31:16 GMT, Inigo Mediavilla Saiz wrote:
>> Print the stack traces of mounted virtual threads when calling `jcmd
>> Thread.print`.
>
> Inigo Mediavilla Saiz has updated the pull request incrementally with one
> additional commit since the last revision:
>
> Print
On Tue, 4 Jun 2024 05:27:48 GMT, David Holmes wrote:
>> Inigo Mediavilla Saiz has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Print mounted virtual thread after carrier
>
> src/hotspot/share/runtime/javaTh
On Mon, 3 Jun 2024 22:03:13 GMT, Chris Plummer wrote:
>> Serguei Spitsyn has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> review: consistency and stylistical corrections
>
> src/hotspot/share/prims/jvmti.xml line 1007:
>
>> 1005:
On Mon, 3 Jun 2024 08:31:46 GMT, Thomas Stuefe wrote:
> I also find the duplication of the stack printing code unfortunate. It would
> be nice to reuse`JavaThread::print_vthread_stack_on`. I don't understand why
> it cannot be const?
Just what I was about to query :) I'm not sure what the
On Fri, 31 May 2024 02:07:25 GMT, David Holmes wrote:
>> Print the stack traces of mounted virtual threads when calling `jcmd
>> Thread.print`.
>
> I'd probably give preference to the stack of the virtual thread, as the stack
> of the carrier when a vthread is mount
On Fri, 31 May 2024 08:07:36 GMT, Serguei Spitsyn wrote:
>> The following RFE was fixed recently:
>> [8324680](https://bugs.openjdk.org/browse/JDK-8324680): Replace NULL with
>> nullptr in JVMTI generated code
>>
>> It replaced all the `NULL`'s in the generated spec with`nullptr`. JVMTI
>>
On Wed, 29 May 2024 18:12:25 GMT, Sonia Zaldana Calles
wrote:
> Hi folks,
>
> This PR addresses [8332785](https://bugs.openjdk.org/browse/JDK-8332785)
> replacing all naked uses for ```UseSharedSpaces``` with
> ```CDSConfig::is_using_archive```.
>
> Testing:
> - [x] Tier 1 with GHA.
>
On Fri, 31 May 2024 01:43:35 GMT, Serguei Spitsyn wrote:
> Okay. I've made a fix to replace in the docs nullptr with null pointer as you
> suggested.
What I suggested was
> returns _a_ null pointer
in place of
> returns `nulllptr`
but "a null pointer" doesn't always look right either e.g.
On Thu, 30 May 2024 14:13:34 GMT, Inigo Mediavilla Saiz
wrote:
> Print the stack traces of mounted virtual threads when calling `jcmd
> Thread.print`.
I'd probably give preference to the stack of the virtual thread, as the stack
of the carrier when a vthread is mounted is generally quite
On Thu, 30 May 2024 14:13:34 GMT, Inigo Mediavilla Saiz
wrote:
> Print the stack traces of mounted virtual threads when calling `jcmd
> Thread.print`.
Do you look at `JavaThread::print_vthread_stack_on`? The last thing we need is
yet-another-version of stack printing code.
-
On Wed, 29 May 2024 09:09:16 GMT, Matthias Baesken wrote:
> When running with ubsan - enabled binaries (--enable-ubsan),
> in the vmTestbase/nsk/jdi tests some cases of memset on nullptr destinations
> are detected in get_object_monitor_usage .
>
> // null out memory for robustness
>
On Thu, 30 May 2024 07:14:13 GMT, Alan Bateman wrote:
>> Okay. I still think that should be hidden behind the
>> `java_lang_VirtualThread::is_instance` as it is an implementation detail the
>> JVMTI and thread code shouldn't need to know about IMO. Once the alternative
>> implementation is
On Thu, 30 May 2024 06:31:19 GMT, Alan Bateman wrote:
>> src/hotspot/share/prims/jvmtiEnvBase.cpp line 1486:
>>
>>> 1484: if (owning_thread != nullptr) {
>>> 1485: oop thread_oop = get_vthread_or_thread_oop(owning_thread);
>>> 1486: bool is_virtual =
>>>
On Thu, 30 May 2024 01:13:20 GMT, SendaoYan wrote:
>> Hi all,
>> ObjectMonitorUsage.java failed with `unexpected waiter_count` after
>> [JDK-8328083](https://bugs.openjdk.org/browse/JDK-8328083) on linux x86_32.
>> There are two changes in this PR:
>> 1. In
On Wed, 29 May 2024 01:18:57 GMT, Serguei Spitsyn wrote:
>> Leonid Mesnik has updated the pull request incrementally with two additional
>> commits since the last revision:
>>
>> - fixed space.
>> - The result is updated.
>
> src/hotspot/share/prims/jvmtiTrace.cpp line 284:
>
>> 282:
On Wed, 29 May 2024 12:38:21 GMT, Matthias Baesken wrote:
>> When running with ubsan - enabled binaries (--enable-ubsan),
>> in the vmTestbase/nsk/jdi tests some cases of memset on nullptr destinations
>> are detected in get_object_monitor_usage .
>>
>> // null out memory for robustness
>>
On Fri, 24 May 2024 20:03:53 GMT, Chris Plummer wrote:
> If PointerLocation discovers that an address is for a JNI local ref, it will
> print information about the thread that owns the JNI local ref. For
> JavaThreads it calls the printThreadIDOn(tty) method. There's a comment on
> the call
On Sun, 26 May 2024 09:27:00 GMT, SendaoYan wrote:
> Hi all,
> ObjectMonitorUsage.java failed with `unexpected waiter_count` after
> [JDK-8328083](https://bugs.openjdk.org/browse/JDK-8328083) on linux x86_32.
> It should be predicated with `@requires vm.continuations` to be skipped.
>
>
On Mon, 20 May 2024 03:23:25 GMT, Chris Plummer wrote:
> Unfortunately checking ownership means comparing jobjects, which you can't
> safely do if you are comparing to a jobject that could be freed at any moment
Okay but how does this `dbgRawMonitor` lock prevent the GC from clearing a
On Fri, 17 May 2024 22:31:32 GMT, Leonid Mesnik wrote:
>> The JvmtiTrace::safe_get_thread_name sometimes crashes when called while
>> current thread is in native thread state.
>>
>> It happens when thread_name is set for tracing from jvmti functions.
>> See:
>>
On Fri, 17 May 2024 19:32:31 GMT, Chris Plummer wrote:
>> This PR adds ranked monitor support to the debug agent. The debug agent has
>> a large number of monitors, and it's really hard to know which order to grab
>> them in, and for that matter which monitors might already be held at any
>>
On Fri, 17 May 2024 22:31:32 GMT, Leonid Mesnik wrote:
>> The JvmtiTrace::safe_get_thread_name sometimes crashes when called while
>> current thread is in native thread state.
>>
>> It happens when thread_name is set for tracing from jvmti functions.
>> See:
>>
On Fri, 17 May 2024 02:08:34 GMT, Leonid Mesnik wrote:
>> The JvmtiTrace::safe_get_thread_name sometimes crashes when called while
>> current thread is in native thread state.
>>
>> It happens when thread_name is set for tracing from jvmti functions.
>> See:
>>
On Fri, 17 May 2024 00:43:18 GMT, Serguei Spitsyn wrote:
>> The following RFE was fixed recently:
>> [8324680](https://bugs.openjdk.org/browse/JDK-8324680): Replace NULL with
>> nullptr in JVMTI generated code
>>
>> It replaced all the `NULL`'s in the generated spec with`nullptr`. JVMTI
>>
On Wed, 15 May 2024 05:59:56 GMT, Jaikiran Pai wrote:
> Can I please get a review of this change which removes the
> `test/jdk/com/sun/jdi/cds/` tests from being problem listed when jtreg
> launches these tests through a virtual thread?
>
> These tests aren't actually incompatible with
On Mon, 13 May 2024 15:32:27 GMT, Alan Bateman wrote:
>> Maurizio Cimadamore has updated the pull request incrementally with three
>> additional commits since the last revision:
>>
>> - Fix another typo
>> - Fix typo
>> - Add more comments
>
> src/hotspot/share/runtime/arguments.cpp line
On Tue, 14 May 2024 18:10:28 GMT, Maurizio Cimadamore
wrote:
>> This PR implements [JEP 472](https://openjdk.org/jeps/472), by restricting
>> the use of JNI in the following ways:
>>
>> * `System::load` and `System::loadLibrary` are now restricted methods
>> * `Runtime::load` and
On Tue, 14 May 2024 01:53:20 GMT, Alex Menkov wrote:
>> The fix updates descriptions of `HeapDumpPath`/`HeapDumpGzipLevel` and
>> `HeapDumpBeforeFullGC`/`HeapDumpAfterFullGC`/`HeapDumpOnOutOfMemoryError` VM
>> options
>
> Alex Menkov has updated the pull request incrementally with one
On Sun, 12 May 2024 21:34:41 GMT, Leonid Mesnik wrote:
> The nsk.share.Log doing some cleanup and reporting errors in the cleanup
> method. This method is supposed to be executed by finalizer originally.
> However, now it is called only during shutdown hook.
> The cleanup using Cleaner
On Mon, 13 May 2024 15:53:26 GMT, Leonid Mesnik wrote:
> Every log (as any Finalazible object) is registered using registerCleanup()
But you have changed Log so it is no longer a FinalizableObject. ?? Ah I see
this is what you meant by disabling it. Now a Log is a plain old Java object
with
On Sun, 12 May 2024 21:34:41 GMT, Leonid Mesnik wrote:
> The nsk.share.Log doing some cleanup and reporting errors in the cleanup
> method. This method is supposed to be executed by finalizer originally.
> However, now it is called only during shutdown hook.
> The cleanup using Cleaner
On Mon, 6 May 2024 21:42:10 GMT, Chris Plummer wrote:
>> I don't see how that helps. Access to the field is not protected.
>
> I guess there could be a race if one thread is destroying this monitor while
> another is trying to use it. Thus a thread could be doing something like a
>
On Tue, 7 May 2024 11:53:19 GMT, Pavel Rappo wrote:
> Please review this mechanical change to man pages. This PR should be
> integrated after https://github.com/openjdk/jdk/pull/18787.
I think we may have to restore this to a standalone start-of-release change
done after the other
On Wed, 1 May 2024 23:17:58 GMT, Chris Plummer wrote:
>> Good suggestion, thanks. Then I'd suggest this:
>>
>> // Virtual threads are not supported by the GetObjectMonitorUsage.
>> // Correct the expected values if the test is executed with the
>> //
On Thu, 2 May 2024 00:51:20 GMT, Serguei Spitsyn wrote:
>> Copy and paste issue on my part. I would use "if only virtual threads".
>
> Okay, thanks.
Second suggestion is better. "waited by" is not grammatically correct in this
context.
-
PR Review Comment:
On Wed, 17 Apr 2024 20:42:54 GMT, Alex Menkov wrote:
>> The fix makes VM heap dumping parallel by default.
>> `jcmd GC.heap_dump` and `jmap -dump` had parallel dumping by default, the
>> fix affects `HotSpotDiagnosticMXBean.dumpHeap()`,
>> `-XX:+HeapDumpBeforeFullGC`,
On Fri, 19 Apr 2024 01:16:46 GMT, Alex Menkov wrote:
> The fix deprecates -XX:+UseNotificationThread VM option
>
> Testing: tier1-3,hs-tier5-svc
Changes look good but please ensure tier5 svc tests pass with the warning
enabled
EDIT: Ah I see you already indicated they did - thanks
Thanks.
On Fri, 19 Apr 2024 18:07:00 GMT, Alex Menkov wrote:
> > Have you looked for any tests that are using this option?
>
> No tests use the option
Well they do but it is done via a task definition in hs-tier5-svc.js.
-
PR Comment:
On Tue, 16 Apr 2024 19:45:12 GMT, Alex Menkov wrote:
>> src/hotspot/share/services/heapDumper.hpp line 63:
>>
>>> 61: // additional info is written to out if not null.
>>> 62: // compression >= 0 creates a gzipped file with the given compression
>>> level.
>>> 63: // parallel_thread_num
On Mon, 15 Apr 2024 23:18:54 GMT, Alex Menkov wrote:
>> The fix makes VM heap dumping parallel by default.
>> `jcmd GC.heap_dump` and `jmap -dump` had parallel dumping by default, the
>> fix affects `HotSpotDiagnosticMXBean.dumpHeap()`,
>> `-XX:+HeapDumpBeforeFullGC`,
On Tue, 9 Apr 2024 12:10:57 GMT, Kevin Walls wrote:
> EnableVMInspectCommand
I can live with that.
-
PR Comment: https://git.openjdk.org/jdk/pull/17655#issuecomment-2046351694
On Mon, 8 Apr 2024 15:54:30 GMT, Kevin Walls wrote:
>> Introduce the jcmd "VM.inspect" to implement access to detailed JVM object
>> information.
>>
>> Not recommended for live production use. Requires UnlockDiagnosticVMOptions
>> and not included in jcmd help output, to remind us this is
On Fri, 29 Mar 2024 11:35:57 GMT, Andrei Pangin wrote:
>> This fix makes `AsyncGetCallTrace` reentrant and async-signal-safe.
>> Reentrancy is required in the cases when two or more profiling engines are
>> running at the same time, e.g., when CPU and Wall clock profilers work
>> together and
On Wed, 27 Mar 2024 18:31:50 GMT, Kevin Walls wrote:
>> Introduce the jcmd "VM.inspect" to implement access to detailed JVM object
>> information.
>>
>> Not recommended for live production use. Requires UnlockDiagnosticVMOptions
>> and not included in jcmd help output, to remind us this is
On Mon, 1 Apr 2024 21:07:34 GMT, Daniel D. Daugherty wrote:
> Trivial fixes to ProblemList noisy tests:
>
> [JDK-8329425](https://bugs.openjdk.org/browse/JDK-8329425) ProblemList
> containers/docker/TestJFREvents.java on linux-x64
> [JDK-8329426](https://bugs.openjdk.org/browse/JDK-8329426)
On Wed, 27 Mar 2024 01:02:41 GMT, Andrei Pangin wrote:
> This fix makes `AsyncGetCallTrace` reentrant and async-signal-safe.
> Reentrancy is required in the cases when two or more profiling engines are
> running at the same time, e.g., when CPU and Wall clock profilers work
> together and
On Wed, 27 Mar 2024 13:44:42 GMT, Matthias Baesken wrote:
>> Currently jcmd command GC.heap_dump only works with an additionally provided
>> file name.
>> Syntax : GC.heap_dump [options]
>>
>> In case the JVM has the XX - flag HeapDumpPath set, we should support an
>> additional mode where
On Mon, 18 Mar 2024 13:14:41 GMT, Richard Reingruber wrote:
>> This pr changes `JfrJvmtiAgent::retransform_classes()` and
>> `jfr_set_enabled` to switch to `WXWrite` before transitioning to the vm.
>>
>> Testing:
>> make test TEST=jdk/jfr/event/runtime/TestClassLoadEvent.java
>>
On Tue, 19 Mar 2024 09:30:52 GMT, Andrew Haley wrote:
> That's very odd. The example there doesn't even involve MAP_JIT memory, so
> what does it have to do with WX?
@theRealAph that is the mystery we hope will be resolved once we know the
nature of the underlying OS bug. Somehow switching to
On Mon, 18 Mar 2024 13:14:41 GMT, Richard Reingruber wrote:
>> This pr changes `JfrJvmtiAgent::retransform_classes()` and
>> `jfr_set_enabled` to switch to `WXWrite` before transitioning to the vm.
>>
>> Testing:
>> make test TEST=jdk/jfr/event/runtime/TestClassLoadEvent.java
>>
On Mon, 18 Mar 2024 23:45:29 GMT, Serguei Spitsyn wrote:
>> Please, review this fix correcting the JVMTI `RawMonitorWait()`
>> implementation.
>> The `RawMonitorWait()` is using the the `jt->is_interrupted(true)` to
>> update the interrupt status of the interrupted waiting thread. The issue
On Fri, 15 Mar 2024 11:24:53 GMT, Matthias Baesken wrote:
>> Currently jcmd command GC.heap_dump only works with an additionally provided
>> file name.
>> Syntax : GC.heap_dump [options]
>>
>> In case the JVM has the XX - flag HeapDumpPath set, we should support an
>> additional mode where
On Fri, 15 Mar 2024 20:14:22 GMT, Serguei Spitsyn wrote:
> The `JvmtiHandshake` and `JvmtiUnitedHandshakeClosure` classes were
> introduced in the JDK 22 to unify/simplify the JVM TI functions supporting
> implementation of the virtual threads. This enhancement is to refactor JVM TI
>
On Sat, 9 Mar 2024 05:27:43 GMT, Leonid Mesnik wrote:
>> vmtestbase nsk/jdi tests run 2 processes: debugger and debugee.
>> There is not need to start debugger in the separate process for each test.
>> Also, no need to run it with "-Xcomp" because the main goal is to test
>> debugee behavior
On Mon, 18 Mar 2024 00:12:55 GMT, Alan Bateman wrote:
>> Serguei Spitsyn has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> review: made current changes limitedto just RawMonitorWait
>
> src/hotspot/share/runtime/javaThread.cpp line 596:
>
On Sat, 16 Mar 2024 22:33:49 GMT, Serguei Spitsyn wrote:
>> Please, review this fix correcting the JVMTI `RawMonitorWait()`
>> implementation.
>> The `RawMonitorWait()` is using the the `jt->is_interrupted(true)` to
>> update the interrupt status of the interrupted waiting thread. The issue
On Fri, 15 Mar 2024 09:06:33 GMT, Serguei Spitsyn wrote:
>> Personally I'd prefer to see changes limited to just JVMTI `RawMonitorWait`.
>> That minimises the risk of any unintended consequences from making the
>> change.
>
> I've restored the `InterruptedException` catch in the `Object.wait`.
On Tue, 12 Mar 2024 15:05:00 GMT, Richard Reingruber wrote:
> This pr changes `JfrJvmtiAgent::retransform_classes()` and `jfr_set_enabled`
> to switch to `WXWrite` before transitioning to the vm.
>
> Testing:
> make test TEST=jdk/jfr/event/runtime/TestClassLoadEvent.java
>
On Tue, 12 Mar 2024 08:23:04 GMT, Stefan Karlsson wrote:
> > GC folk should be reviewing this not runtime.
>
> I don't fully agree with that. How these serviceability tools work, and their
> interfaces, are usually not something that we GC devs are directly
> responsible for. This change
On Tue, 12 Mar 2024 15:05:00 GMT, Richard Reingruber wrote:
> This pr changes `JfrJvmtiAgent::retransform_classes()` and `jfr_set_enabled`
> to switch to `WXWrite` before transitioning to the vm.
>
> Testing:
> make test TEST=jdk/jfr/event/runtime/TestClassLoadEvent.java
>
On Mon, 11 Mar 2024 11:57:04 GMT, Matthias Baesken wrote:
> Currently jcmd command GC.heap_dump only works with an additionally provided
> file name.
> Syntax : GC.heap_dump [options]
>
> In case the JVM has the XX - flag HeapDumpPath set, we should support an
> additional mode where the is
On Mon, 11 Mar 2024 08:50:09 GMT, Matthias Baesken wrote:
>> There are a number of places remaining in the linux/macOS native JDK
>> codebase where we use the RESTARTABLE macro with close, but this is unwanted
>> on Linux/macOS.
>
> Matthias Baesken has updated the pull request incrementally
On Sat, 9 Mar 2024 05:27:43 GMT, Leonid Mesnik wrote:
>> vmtestbase nsk/jdi tests run 2 processes: debugger and debugee.
>> There is not need to start debugger in the separate process for each test.
>> Also, no need to run it with "-Xcomp" because the main goal is to test
>> debugee behavior
On Tue, 12 Mar 2024 02:31:43 GMT, Serguei Spitsyn wrote:
>> The implementation of the JVM TI `GetObjectMonitorUsage` does not match the
>> spec.
>> The function returns the following structure:
>>
>>
>> typedef struct {
>> jthread owner;
>> jint entry_count;
>> jint waiter_count;
On Sat, 9 Mar 2024 05:27:43 GMT, Leonid Mesnik wrote:
>> vmtestbase nsk/jdi tests run 2 processes: debugger and debugee.
>> There is not need to start debugger in the separate process for each test.
>> Also, no need to run it with "-Xcomp" because the main goal is to test
>> debugee behavior
On Fri, 8 Mar 2024 12:12:30 GMT, Matthias Baesken wrote:
>> src/jdk.attach/linux/native/libattach/VirtualMachineImpl.c line 200:
>>
>>> 198: if (res == -1) {
>>> 199: JNU_ThrowIOExceptionWithLastError(env, "close");
>>> 200: }
>>
>> I assume it would be better to not throw when
On Mon, 4 Mar 2024 10:09:10 GMT, Serguei Spitsyn wrote:
>> test/hotspot/jtreg/serviceability/jvmti/ObjectMonitorUsage/ObjectMonitorUsage.java
>> line 319:
>>
>>> 317: try {
>>> 318: ready = true;
>>> 319: lockCheck.wait();
>>
>> Spurious
On Tue, 5 Mar 2024 09:04:08 GMT, Serguei Spitsyn wrote:
>> The loop is endless without this extra condition, so we are getting a test
>> execution timeout.
>> The `waiters` seems to be `circular doubly linked list` as we can see below:
>>
>> inline void ObjectMonitor::AddWaiter(ObjectWaiter*
On Fri, 8 Mar 2024 06:11:23 GMT, Serguei Spitsyn wrote:
>> The implementation of the JVM TI `GetObjectMonitorUsage` does not match the
>> spec.
>> The function returns the following structure:
>>
>>
>> typedef struct {
>> jthread owner;
>> jint entry_count;
>> jint waiter_count;
On Thu, 7 Mar 2024 08:42:11 GMT, Alan Bateman wrote:
>> Use of `ObjectLocker` here will introduce a new pinning point for Loom. We
>> have been removing as many uses of `ObjectLocker` as we can. I also think
>> this will need to be moved back to Java code when the pinning currently
>>
On Thu, 7 Mar 2024 13:21:09 GMT, Coleen Phillimore wrote:
>> This change creates a new sort of native recursive lock that can be held
>> during JNI and Java calls, which can be used for synchronization while
>> creating objArrayKlasses at runtime.
>>
>> Passes tier1-7.
>
> Coleen Phillimore
On Thu, 7 Mar 2024 08:16:26 GMT, Matthias Baesken wrote:
>> We define the RESTARTABLE macro again and again at a lot of places in the
>> JDK native codebase. This could be centralized to avoid repeating it again
>> and again !
>
> Matthias Baesken has updated the pull request incrementally
On Thu, 7 Mar 2024 03:00:11 GMT, Guoxiong Li wrote:
>> Matthias Baesken has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Introduce windows jni_util_md.h
>
> src/java.base/aix/native/libnio/ch/Pollset.c line 3:
>
>> 1: /*
>> 2: *
On Wed, 6 Mar 2024 10:41:21 GMT, Serguei Spitsyn wrote:
>> Thanks, I'm already working on it.
>
> Fixed as suggested by Alan.
>
>> Also need to think through if Object.wait will need to be changed as part of
>> this.
>
> Still need to look at this.
Use of `ObjectLocker` here will introduce a
On Thu, 7 Mar 2024 01:38:56 GMT, Coleen Phillimore wrote:
>> This change creates a new sort of native recursive lock that can be held
>> during JNI and Java calls, which can be used for synchronization while
>> creating objArrayKlasses at runtime.
>>
>> Passes tier1-7.
>
> Coleen Phillimore
On Thu, 7 Mar 2024 01:38:56 GMT, Coleen Phillimore wrote:
>> This change creates a new sort of native recursive lock that can be held
>> during JNI and Java calls, which can be used for synchronization while
>> creating objArrayKlasses at runtime.
>>
>> Passes tier1-7.
>
> Coleen Phillimore
On Thu, 7 Mar 2024 00:16:39 GMT, Dean Long wrote:
>> Semaphore seemed simpler (?)
>
> OK. It's a good thing HotSpot doesn't need to worry about
> priority-inheritance for mutexes.
Semaphore seems simpler/cleaner and ready to use.
-
PR Review Comment:
On Tue, 5 Mar 2024 23:13:30 GMT, Dean Long wrote:
> I'm wondering if your new recursive lock class could use the existing
> ObjectMonitor.
There has been a drive to remove `ObjectLocker` from the C++ code due to the
negative impact on Loom. Also not sure what existing `ObjectMonitor` you are
On Tue, 5 Mar 2024 19:57:39 GMT, Serguei Spitsyn wrote:
> The behavior of ObjectMonitor::wait and RawMonitorWait is different.
The Object.wait() throws the InterruptedException if it was interrupted. The
RawMonitorWait clears the thread interrupt status and returns the error code
On Tue, 6 Feb 2024 22:59:04 GMT, Coleen Phillimore wrote:
> This change creates a new sort of native recursive lock that can be held
> during JNI and Java calls, which can be used for synchronization while
> creating objArrayKlasses at runtime.
>
> Passes tier1-4.
On Tue, 5 Mar 2024 06:16:04 GMT, Serguei Spitsyn wrote:
>> Please, review this fix correcting the JVMTI `RawMonitorWait()`
>> implementation.
>> The `RawMonitorWait()` is using the the `jt->is_interrupted(true)` to
>> update the interrupt status of the interrupted waiting thread. The issue
On Tue, 5 Mar 2024 03:40:04 GMT, Serguei Spitsyn wrote:
>> The implementation of the JVM TI `GetObjectMonitorUsage` does not match the
>> spec.
>> The function returns the following structure:
>>
>>
>> typedef struct {
>> jthread owner;
>> jint entry_count;
>> jint waiter_count;
Hi Sonia,
Adding serviceability and Alan Bateman ...
On 5/03/2024 2:35 am, Sonia Zaldana Calles wrote:
Hi folks,
I’m working on JDK-8324683 [0].
I’m hoping to unify the code for attachListener_.cpp for posix
platforms.
While reviewing linux against bsd, I noted a difference in
On Fri, 1 Mar 2024 11:19:21 GMT, Serguei Spitsyn wrote:
>> 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
On Sat, 2 Mar 2024 07:58:40 GMT, Alan Bateman wrote:
>> Please, review this fix correcting the JVMTI `RawMonitorWait()`
>> implementation.
>> The `RawMonitorWait()` is using the the `jt->is_interrupted(true)` to
>> update the interrupt status of the interrupted waiting thread. The issue is
1 - 100 of 906 matches
Mail list logo
