On Thu, 7 Mar 2024 07:20:15 GMT, David Holmes wrote:
> Oracle requests/requires that the Oracle copyright always be updated when a
> file is modified.
Got it. Thanks for your explanation.
-
PR Review Comment: https://git.openjdk.org/jdk/pull/18132#discussion_r1515672685
On Thu, 7 Mar 2024 00:13:56 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 i
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: * Copyrig
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 Wed, 6 Mar 2024 16:30:23 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 with
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 ha
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 ha
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 ha
On Thu, 7 Mar 2024 00:54:30 GMT, David Holmes wrote:
>> 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.
It's such a rare race and unusual condition that we could execute more Java
code, that I
On Thu, 7 Mar 2024 00:18:53 GMT, Dean Long wrote:
>> Coleen Phillimore has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Dean's comments.
>
> src/hotspot/share/oops/arrayKlass.cpp line 135:
>
>> 133: ResourceMark rm(THREAD);
>> 134:
On Thu, 7 Mar 2024 01:35:45 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 ha
> 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 has updated the pull request incrementally with one
additional commit
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: https://git.openjdk.org/jdk/p
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-7.
Marked as reviewed by dlong
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-7.
src/hotspot/share/oops/insta
On Tue, 5 Mar 2024 23:11:07 GMT, David Holmes wrote:
> Okay so that is where the carrier and virtual thread states get back in sync,
> and that is what is missing in the `RawMonitorWait` case. The proposed
> fix/change to `is_interrupted` is what threw me as that is the wrong place to
> make a
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-7.
src/hotspot/share/oops/array
On Wed, 6 Mar 2024 23:47:01 GMT, Coleen Phillimore wrote:
>> src/hotspot/share/runtime/mutex.cpp line 537:
>>
>>> 535: // can be called by jvmti by VMThread.
>>> 536: if (current->is_Java_thread()) {
>>> 537: _sem.wait_with_safepoint_check(JavaThread::cast(current));
>>
>> Why not
On Wed, 6 Mar 2024 18:56:54 GMT, Alan Bateman wrote:
> I think you can drop the catch of InterruptedException in Object.wait now.
> Easy to check this by running
> test/jdk/java/lang/Thread/virtual/MonitorWaitNotify.java as it has tests for
> interrupting Object.wait.
Thanks. Fixed now. Teste
> 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 that
> when it calls `jt->is_interrupted(true)` to fetch an
On Fri, 23 Feb 2024 21:55:15 GMT, Chris Plummer wrote:
> PerfMapTest.java issues the Compiler.perfmap jcmd with a filename argument to
> write the perfmap to. It does this in 3 different modes. 2 of the modes
> result in a perfmap file being left in the tmp directory that is not removed
> afte
On Wed, 6 Mar 2024 23:09:34 GMT, Dean Long 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.
>
> src/hotspot/share/runtime/mu
On Wed, 6 Mar 2024 16:30:23 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 with
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-7.
OK, that makes sense about l
On Wed, 6 Mar 2024 10:44:15 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 i
On Wed, 6 Mar 2024 16:30:23 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 with
> 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 with one additional
commit since the last revision:
Introduce win
On Wed, 6 Mar 2024 15:49:05 GMT, Alan Bateman wrote:
>> Matthias Baesken has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> introduce unix jni_util_md.h
>
> src/java.base/aix/native/libnio/ch/Pollset.c line 29:
>
>> 27: #include "jni.h"
>>
On Wed, 6 Mar 2024 15:45:16 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 with
> 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 with one additional
commit since the last revision:
introduce uni
On Wed, 6 Mar 2024 14:25:09 GMT, Matthias Baesken wrote:
> We could maybe also use the existing
> https://github.com/openjdk/jdk/blob/master/src/java.base/unix/native/include/jni_md.h
> - what do you think ?
jni_md.h goes into the JDK run-time image (for jni.h to include) so I don't
think we
On Wed, 6 Mar 2024 14:13:26 GMT, Alan Bateman 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 !
>
> src/java.base/share/native/libjava/jni_util.h line 243:
>
>> 241:
On Wed, 6 Mar 2024 09:26:25 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 !
src/java.base/share/native/libjava/jni_util.h line 243:
> 241: } wh
On Tue, 5 Mar 2024 23:13:30 GMT, Dean Long 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.
>
> Is the caller always a JavaT
On Tue, 5 Mar 2024 11:31:13 GMT, Kevin Walls wrote:
>> Introduce the jcmd "VM.debug" to implement access to a useful set of the
>> established debug.cpp utilities, with "jcmd PID VM.debug subcommand ...".
>>
>> Not recommended for live production use. Calling these "debug" utilities,
>> and n
On Tue, 5 Mar 2024 11:31:13 GMT, Kevin Walls wrote:
>> Introduce the jcmd "VM.debug" to implement access to a useful set of the
>> established debug.cpp utilities, with "jcmd PID VM.debug subcommand ...".
>>
>> Not recommended for live production use. Calling these "debug" utilities,
>> and n
> The deprecated Subject Delegation feature in JMX will be removed.
>
> This was marked in JDK 21 as deprecated for removal (JDK-8298966).
Kevin Walls has updated the pull request incrementally with one additional
commit since the last revision:
Test specifically that UOE is thrown.
On Wed, 6 Mar 2024 11:42:18 GMT, Kevin Walls wrote:
>> The deprecated Subject Delegation feature in JMX will be removed.
>>
>> This was marked in JDK 21 as deprecated for removal (JDK-8298966).
>
> Kevin Walls has updated the pull request incrementally with one additional
> commit since the las
> The deprecated Subject Delegation feature in JMX will be removed.
>
> This was marked in JDK 21 as deprecated for removal (JDK-8298966).
Kevin Walls has updated the pull request incrementally with one additional
commit since the last revision:
Test that SubjectDelegation is refused.
--
On Wed, 6 Mar 2024 09:26:25 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 !
Looks good. Nice refactor.
-
Marked as reviewed by gli (
On Wed, 6 Mar 2024 09:34:40 GMT, Serguei Spitsyn wrote:
>> src/hotspot/share/runtime/javaThread.cpp line 573:
>>
>>> 571:
>>> 572: Handle thread_h(current, vthread_or_thread());
>>> 573: ObjectLocker lock(Handle(current,
>>> java_lang_Thread::interrupt_lock(thread_h())), current);
>>
>> F
> 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 that
> when it calls `jt->is_interrupted(true)` to fetch an
On Wed, 6 Mar 2024 09:27:18 GMT, Alan Bateman wrote:
>> Serguei Spitsyn has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> removed trailing spaces in javaClasses.cpp and libInterruptRawMonitor.cpp
>
> src/hotspot/share/runtime/javaThread.cp
> 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 that
> when it calls `jt->is_interrupted(true)` to fetch an
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 !
-
Commit messages:
- JDK-8327444
Changes: https://git.openjdk.org/jdk/pull/18132/files
Webrev: https://webrevs.openjdk.
On Wed, 6 Mar 2024 09:14:18 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 i
> 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 that
> when it calls `jt->is_interrupted(true)` to fetch an
On Wed, 6 Mar 2024 06:28:01 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 i
> 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 that
> when it calls `jt->is_interrupted(true)` to fetch an
49 matches
Mail list logo
