On Fri, 8 Mar 2024 05:56:24 GMT, Serguei Spitsyn wrote:
> > Can you check if
> > vmTestbase/nsk/jvmti/scenarios/bcinstr/BI04/bi04t002/TestDescription.java
> > is passing now? That test is a bit annoying in that it fails every time we
> > touch j.l.Object so you might have to update
> > BI04/b
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
>> inherent
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 ha
> 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
> 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;
> jthread* waiters;
> jint notify_waiter_count;
> jthread
> 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 this update the `GetCurrentContendedMonitor()` is returning the mo
On Thu, 7 Mar 2024 07:28:31 GMT, Alan Bateman wrote:
> Can you check if
> vmTestbase/nsk/jvmti/scenarios/bcinstr/BI04/bi04t002/TestDescription.java is
> passing now? That test is a bit annoying in that it fails every time we touch
> j.l.Object so you might have to update
> BI04/bi04t002/newcl
On Fri, 8 Mar 2024 02:35:08 GMT, Man Cao wrote:
>> Hi all,
>>
>> Could anyone review this fix to make serial heap dump only write to a single
>> file?
>> We highly appreciate the work in
>> https://bugs.openjdk.org/browse/JDK-8306441. However, many of our customers
>> still need to use serial
On Fri, 8 Mar 2024 02:35:08 GMT, Man Cao wrote:
>> Hi all,
>>
>> Could anyone review this fix to make serial heap dump only write to a single
>> file?
>> We highly appreciate the work in
>> https://bugs.openjdk.org/browse/JDK-8306441. However, many of our customers
>> still need to use serial
RecordComponent class has _attributes_count field.
The only user of the field is JvmtiClassFileReconstituter. Incorrect value of
the field causes producing incorrect data for Record attribute.
Parsing Record attribute ClassFileParser skips unknown attributes and may skip
RuntimeInvisibleAnnotatio
> 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 three additional
commits since the last revision:
- Clarify deprecation comment.
- typo
- Rem
On Thu, 7 Mar 2024 20:07:57 GMT, Sean Mullan wrote:
>> Kevin Walls has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Test specifically that UOE is thrown.
>
> src/java.management/share/classes/javax/management/remote/JMXConnector.java
> l
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 ha
On Wed, 6 Mar 2024 11:46:16 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
On Wed, 6 Mar 2024 11:46:16 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
On Wed, 6 Mar 2024 11:46:16 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
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 with
On Thu, 7 Mar 2024 01:44:22 GMT, David Holmes wrote:
>> Coleen Phillimore has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Dean's comments.
>
> src/hotspot/share/oops/instanceKlass.cpp line 1552:
>
>> 1550: RecursiveLocker rl(MultiAr
On Thu, 7 Mar 2024 01:31:09 GMT, Coleen Phillimore wrote:
>> 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 started out with just a shared bit. Then David suggested a
> semaphore that obeys the sa
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
> 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 two
additional commit
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 with
On Tue, 5 Mar 2024 19:53:46 GMT, Weijun Wang wrote:
>> Subject is stored in the RMIConnectionImpl:
>> src/java.management.rmi/share/classes/javax/management/remote/rmi/RMIConnectionImpl.java
>>
>> (That is complicated by SubjectDelegation, which we deprecated for removal.
>> I have the PR out
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 with
On Thu, 7 Mar 2024 08:08:45 GMT, Alan Bateman wrote:
> Latest version looks good to me. As have been pointed out, there at least 2
> files where the copyright header was updated but there are no changes, I
> assume left over from previous iterations. I assume the RESTARTABLE-close in
> libatta
On Thu, 7 Mar 2024 06:45:01 GMT, David Holmes wrote:
>> 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 new pinning point for Loom. We
>
On Wed, 6 Mar 2024 17:16:03 GMT, Christoph Langer wrote:
>> Matthias Baesken has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> adjust COPYRIGHT year info
>
> src/java.base/unix/native/libjava/childproc.h line 75:
>
>> 73: #define FAIL_FIL
On Wed, 6 Mar 2024 17:14:25 GMT, Christoph Langer 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/share/native/libjava/jni_util.h line 30:
>
>> 28:
>> 29: #in
> 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:
adjust COPYRI
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
30 matches
Mail list logo
