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
On Fri, 1 Mar 2024 11:50:05 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 Fri, 1 Mar 2024 11:50:05 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, 29 Feb 2024 01:50:02 GMT, Alex Menkov wrote:
> Many NSK tests create socket channel for test/target interprocess
> communication.
> The change updates server side to listen only on loopback interface.
>
> Testing - all tests that use then functionality:
> -
On Tue, 26 Dec 2023 14:15:17 GMT, Taizo Kurashige wrote:
>> Hi,
>>
>> I fixed the typos for JFR.start and JFR.dump.
>> Acconding to issue's description, there is some typo in JFR.stop
>> documentation, but I couldn't find that. I confirmed that there is no such
>> typo in this repository. So
On Sun, 25 Feb 2024 10:53:20 GMT, Alan Bateman wrote:
>> This enhancement replaces uses of NULL with nullptr in the XML-description
>> files for JVMTI. These are the files `hotsport/share/prims/jvmti.xml` and
>> `hotspot/share/prims/jvmti*.xls`.
>>
>> The following files are auto-generated
On Mon, 19 Feb 2024 15:33: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, 15 Feb 2024 19:55:08 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 Wed, 14 Feb 2024 12:16:38 GMT, Serguei Spitsyn wrote:
>> src/hotspot/share/runtime/threads.cpp line 1200:
>>
>>> 1198: if (pending == monitor ||
>>> 1199: (waiting == monitor &&
>>> JavaThreadStatus::BLOCKED_ON_MONITOR_ENTER ==
>>> 1200:
On Tue, 13 Feb 2024 07:11:18 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 Tue, 13 Feb 2024 08:34:57 GMT, Serguei Spitsyn wrote:
>> test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetObjectMonitorUsage/objmonusage003.java
>> line 33:
>>
>>> 31: final static int NUMBER_OF_ENTERER_THREADS = 4;
>>> 32: final static int NUMBER_OF_WAITER_THREADS = 4;
>>> 33: final
On Sat, 10 Feb 2024 04:06:37 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 Wed, 7 Feb 2024 07:02:11 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 Mon, 5 Feb 2024 21:58:23 GMT, Joe Darcy wrote:
>> This update drops the "ea" from the version string.
>>
>> We also propagate the following fixes from the markdown sources to the troff
>> manpage file:
>>
>> JDK-8322478: Update java manpage for multi-file source-code launcher
>>
On Sun, 4 Feb 2024 22:43:28 GMT, David Holmes wrote:
> This update drops the "ea" from the version string.
>
> We also propagate the following fixes from the markdown sources to the troff
> manpage file:
>
> JDK-8322478: Update java manpage for multi-file source
On Wed, 31 Jan 2024 14:22:44 GMT, Kevin Walls wrote:
> not including them in the jcmd help output, is to remind us they are not
> general customer-facing tools.
Then who are they for? and do they really belong in the `jcmd` tool, or is that
just convenient?
Without help information who will
This update drops the "ea" from the version string.
We also propagate the following fixes from the markdown sources to the troff
manpage file:
JDK-8322478: Update java manpage for multi-file source-code launcher
JDK-8302233: HSS/LMS: keytool and jarsigner changes
JDK-8318971: Better Error
On Thu, 1 Feb 2024 18:25:33 GMT, Doug Simon wrote:
> The `com/sun/management/ThreadMXBean/ThreadCpuTimeArray.java` can transiently
> fail when run with `-Xcomp`. This happens when the compilation of methods on
> the worker threads interleaves with the 2 calls on the main thread to
>
On Fri, 2 Feb 2024 00:44:00 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 Wed, 31 Jan 2024 15:15:16 GMT, Kim Barrett wrote:
>> Please review this trivial change that renames the file
>> test/hotspot/jtreg/vmTestbase/nsk/share/jvmti/Injector.h to Injector.hpp.
>>
>> Testing: mach5 tier1
>
> Kim Barrett has updated the pull request incrementally with one additional
On Wed, 31 Jan 2024 07:52:18 GMT, Jaikiran Pai wrote:
>> src/jdk.jdwp.agent/unix/native/libjdwp/exec_md.c line 35:
>>
>>> 33: #include "sys.h"
>>> 34: #include "util.h"
>>> 35: #include "error_messages.h"
>>
>> Nit: to maintain include sort order this should have gone where
>>
On Wed, 31 Jan 2024 08:01:15 GMT, Jaikiran Pai wrote:
>> Can I please get a review of this change which proposes to address
>> https://bugs.openjdk.org/browse/JDK-8324668?
>>
>> This change proposes to fix the issue in jdwp where when launching a child
>> process (for the `launch=` option),
1 - 100 of 885 matches
Mail list logo
