Re: RFR: 8256314: JVM TI GetCurrentContendedMonitor is implemented incorrectly [v4]

2024-03-03 Thread David Holmes
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 this

Re: RFR: 8326583: Remove over-generalized DefineNativeToolchain solution [v4]

2024-03-03 Thread Julian Waters
On Tue, 27 Feb 2024 11:19:59 GMT, Magnus Ihse Bursie wrote: >> The idea of setting up general "toolchains" in the native build was good, >> but it turned out that we really only need a single toolchain, with a single >> twist: if it should use CC or CPP to link. This is better described by a >

Re: RFR: 8325187: JVMTI GetThreadState says virtual thread is JVMTI_THREAD_STATE_INTERRUPTED when it no longer is

2024-03-03 Thread David Holmes
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

Re: RFR: 8247972: incorrect implementation of JVM TI GetObjectMonitorUsage [v21]

2024-03-03 Thread David Holmes
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; >>

Re: RFR: 8247972: incorrect implementation of JVM TI GetObjectMonitorUsage [v21]

2024-03-03 Thread David Holmes
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; >>

Re: RFR: 8326583: Remove over-generalized DefineNativeToolchain solution [v4]

2024-03-03 Thread Claudio Nieder
On Tue, 27 Feb 2024 11:19:59 GMT, Magnus Ihse Bursie wrote: >> The idea of setting up general "toolchains" in the native build was good, >> but it turned out that we really only need a single toolchain, with a single >> twist: if it should use CC or CPP to link. This is better described by a >

Re: RFR: 8326583: Remove over-generalized DefineNativeToolchain solution [v4]

2024-03-03 Thread Claudio Nieder
On Tue, 27 Feb 2024 11:19:59 GMT, Magnus Ihse Bursie wrote: >> The idea of setting up general "toolchains" in the native build was good, >> but it turned out that we really only need a single toolchain, with a single >> twist: if it should use CC or CPP to link. This is better described by a >

Re: RFR: 8326583: Remove over-generalized DefineNativeToolchain solution [v4]

2024-03-03 Thread Magnus Ihse Bursie
On Tue, 27 Feb 2024 11:19:59 GMT, Magnus Ihse Bursie wrote: >> The idea of setting up general "toolchains" in the native build was good, >> but it turned out that we really only need a single toolchain, with a single >> twist: if it should use CC or CPP to link. This is better described by a >

Re: RFR: 8326583: Remove over-generalized DefineNativeToolchain solution [v4]

2024-03-03 Thread Magnus Ihse Bursie
On Tue, 27 Feb 2024 11:19:59 GMT, Magnus Ihse Bursie wrote: >> The idea of setting up general "toolchains" in the native build was good, >> but it turned out that we really only need a single toolchain, with a single >> twist: if it should use CC or CPP to link. This is better described by a >