On Tue, 5 Mar 2024 01:06:32 GMT, Serguei Spitsyn wrote:
>>> AFAIK, as it is not a good idea to post the JVMTI events recursively
>>
>> We already do. When the debug agent is handling a JVMTI event and
>> RawMonitorWait is interrupted, that results in the debug agent later on
>> calling
On Mon, 4 Mar 2024 09:51:32 GMT, Serguei Spitsyn wrote:
>> src/hotspot/share/prims/jvmtiEnvBase.cpp line 941:
>>
>>> 939: bool is_virtual = java_lang_VirtualThread::is_instance(thread_oop);
>>> 940: jint state = is_virtual ?
>>> JvmtiEnvBase::get_vthread_state(thread_oop, java_thread)
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;
> 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
> 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
On Mon, 4 Mar 2024 22:04:39 GMT, Chris Plummer 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
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 Mon, 4 Mar 2024 09:49:07 GMT, Serguei Spitsyn wrote:
>> src/java.se/share/data/jdwp/jdwp.spec line 1985:
>>
>>> 1983: "thread may be waiting to enter the object's monitor, or in "
>>> 1984: "java.lang.Object.wait waiting to re-enter the monitor after
>>> being "
>>> 1985:
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
> 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
> 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;
>
On Tue, 5 Mar 2024 02:24:50 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:
>> -
> 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:
> - test/hotspot/jtreg/vmTestbase/nsk/jdb,
> test/hotspot/jtreg/vmTestbase/nsk/jdi,
On Mon, 4 Mar 2024 19:35:48 GMT, Chris Plummer wrote:
>> Hello Chris, I haven't followed this PR and this is just a drive by comment
>> about the exception handling discussion. In some other areas of our JDK
>> tests, for situations like this, we do the following:
>>
>>
>> Throwable failure
On Mon, 4 Mar 2024 10:02:03 GMT, Serguei Spitsyn wrote:
>> src/hotspot/share/prims/jvmtiEnvBase.cpp line 1552:
>>
>>> 1550: // If the thread was found on the ObjectWaiter list, then
>>> 1551: // it has not been notified. This thread can't change the
>>> 1552: // state of
On Tue, 5 Mar 2024 00:54:10 GMT, Chris Plummer wrote:
>> @AlanBateman said:
>>> So minimally RawMonitorWait will need to disable suspend and and clear the
>>> interrupt status of both threads while holding the interrupt lock.
>>
>> If we do it with a Java upcall to the
On Mon, 4 Mar 2024 23:35:16 GMT, Serguei Spitsyn wrote:
> AFAIK, as it is not a good idea to post the JVMTI events recursively
We already do. When the debug agent is handling a JVMTI event and
RawMonitorWait is interrupted, that results in the debug agent later on calling
InterrtupThread
On Mon, 4 Mar 2024 11:51:01 GMT, Alan Bateman wrote:
>> Alan and David, thank you for the comments!
>> The initial implementation of the `is_iterrupt()` intentionally avoided any
>> synchronization and allowed a potential raises with the concurrent
>> interrupts. Please, see the comment above
On Fri, 1 Mar 2024 23:26:48 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 is
On Mon, 4 Mar 2024 15:10:12 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
On Mon, 4 Mar 2024 11:51:01 GMT, Alan Bateman wrote:
>> Alan and David, thank you for the comments!
>> The initial implementation of the `is_iterrupt()` intentionally avoided any
>> synchronization and allowed a potential raises with the concurrent
>> interrupts. Please, see the comment above
> This code change adds an alternative implementation of user-based
> authorization `Subject` APIs that doesn't depend on Security Manager APIs.
> Depending on if the Security Manager is allowed, the methods store the
> current subject differently. See the spec change in the `Subject.java` file
On Mon, 4 Mar 2024 16:17:14 GMT, Sean Mullan wrote:
>> Weijun Wang has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> fix MBeanServerFileAccessController, more test in SM
>
> src/java.base/share/classes/javax/security/auth/Subject.java
On Mon, 4 Mar 2024 15:47:41 GMT, Sean Mullan wrote:
>> Weijun Wang has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> fix MBeanServerFileAccessController, more test in SM
>
> test/jdk/javax/security/auth/Subject/CallAsWithScopedValue.java
On Mon, 4 Mar 2024 15:15:54 GMT, Sean Mullan wrote:
>> Weijun Wang has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> fix MBeanServerFileAccessController, more test in SM
>
> test/jdk/javax/management/monitor/ThreadPoolAccTest.java line
On Mon, 4 Mar 2024 19:51:38 GMT, Weijun Wang wrote:
>> src/java.management/share/classes/com/sun/jmx/remote/security/MBeanServerFileAccessController.java
>> line 309:
>>
>>> 307: final Subject s;
>>> 308: if (!SharedSecrets.getJavaLangAccess().allowSecurityManager())
>>> {
>>>
On Mon, 4 Mar 2024 15:28:28 GMT, Sean Mullan wrote:
>> Weijun Wang has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> fix MBeanServerFileAccessController, more test in SM
>
>
On Sat, 2 Mar 2024 06:21:09 GMT, Jaikiran Pai wrote:
>> The one issue with the first variant is that when run() throws an exception,
>> it will be printed twice, assuming deleteIfExists() does not throw an
>> exception. Basically you either get the exception printed twice, or you get
>> the
> Compiler Control (https://openjdk.org/jeps/165) provides method-context
> dependent control of the JVM compilers (C1 and C2). The active directive
> stack is built from the directive files passed with the
> `-XX:CompilerDirectivesFile` diagnostic command-line option and the
>
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
On Tue, 30 Jan 2024 21:58:28 GMT, Weijun Wang wrote:
>> This code change adds an alternative implementation of user-based
>> authorization `Subject` APIs that doesn't depend on Security Manager APIs.
>> Depending on if the Security Manager is allowed, the methods store the
>> current subject
On Mon, 4 Mar 2024 15:10:12 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
On Mon, 4 Mar 2024 13:37:53 GMT, Alan Bateman wrote:
>> Kevin Walls has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> RMIConnection comments update
>
> src/java.management.rmi/share/classes/javax/management/remote/rmi/RMIConnection.java
>
> 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 two additional
commits since the last revision:
- Update doc comments for RMIConnection.
On Tue, 30 Jan 2024 21:58:28 GMT, Weijun Wang wrote:
>> This code change adds an alternative implementation of user-based
>> authorization `Subject` APIs that doesn't depend on Security Manager APIs.
>> Depending on if the Security Manager is allowed, the methods store the
>> current subject
On Tue, 30 Jan 2024 21:58:28 GMT, Weijun Wang wrote:
>> This code change adds an alternative implementation of user-based
>> authorization `Subject` APIs that doesn't depend on Security Manager APIs.
>> Depending on if the Security Manager is allowed, the methods store the
>> current subject
On Mon, 4 Mar 2024 13:24:05 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
On Tue, 30 Jan 2024 21:58:28 GMT, Weijun Wang wrote:
>> This code change adds an alternative implementation of user-based
>> authorization `Subject` APIs that doesn't depend on Security Manager APIs.
>> Depending on if the Security Manager is allowed, the methods store the
>> current subject
> 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 not including them in the jcmd help output, is to remind us
On Tue, 27 Feb 2024 01:30:27 GMT, Serguei Spitsyn wrote:
>> Kevin Walls has updated the pull request incrementally with three additional
>> commits since the last revision:
>>
>> - Usage correction
>> - Help to clarify this is VM inspection. Comment to relate source to
>> debug.cpp.
>> -
On Mon, 4 Mar 2024 11:45:59 GMT, Julian Waters wrote:
> I do hope that dropping ccache support isn't something that's planned though
> :(
Not really. The benefit of dropping it is quite small, and there might be use
cases where it helps.
But I think we should perhaps be more explicit in the
On Mon, 4 Mar 2024 13:24:05 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
> 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:
RMIConnection comments update
-
On Mon, 4 Mar 2024 12:58:28 GMT, Claudio Nieder wrote:
> > Could I trouble you to mention what exactly was different?
>
> No trouble at all.
>
> `CCACHE_BASEDIR=/tmp/bceaed6d/jdk/`is completely missing. (The directory is
> where I checked out OpenJDK)
>
> `CCACHE_SLOPPINESS` has the value
On Mon, 4 Mar 2024 11:45:59 GMT, Julian Waters wrote:
> Could I trouble you to mention what exactly was different?
No trouble at all.
`CCACHE_BASEDIR=/tmp/bceaed6d/jdk/`is completely missing. (The directory is
where I checked out OpenJDK)
`CCACHE_SLOPPINESS` has the value
core-libs-dev is the place to send this.
-Alan
On 04/03/2024 12:11, S A wrote:
Hi all,
after moving our application to Java 21 (up from Java 17), we noticed
a class loader leak. A memory snapshot points to a ProtectionDomain
object held by a ForkJoinWorkerThread, the protection domain holds
Hi all,
after moving our application to Java 21 (up from Java 17), we noticed a
class loader leak. A memory snapshot points to a ProtectionDomain object
held by a ForkJoinWorkerThread, the protection domain holds the class
loader and prevents GC.
To reproduce outside of our application, we use
On Mon, 4 Mar 2024 09:45:59 GMT, Serguei Spitsyn wrote:
>> On that note, note that the entire comment block preceding this needs to be
>> updated for virtual threads. And it is far from clear to me how to correctly
>> manage the interrupt state of virtual threads within the VM, when it
>>
On Mon, 4 Mar 2024 11:28:02 GMT, Magnus Ihse Bursie wrote:
> > I wonder if it's the SetupToolchain changes that has caused this. ccache is
> > collapsed into CC and CXX to my knowledge
>
> Yeah, it must have been. Would you like to take a look at it? Otherwise I'll
> file a bug and fix it.
On Mon, 4 Mar 2024 06:42:30 GMT, Julian Waters wrote:
> I wonder if it's the SetupToolchain changes that has caused this. ccache is
> collapsed into CC and CXX to my knowledge
Yeah, it must have been. Would you like to take a look at it? Otherwise I'll
file a bug and fix it. Breaking ccache
On Mon, 4 Mar 2024 03:28:28 GMT, David Holmes wrote:
>> Serguei Spitsyn has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> rename after merge: jvmti_common.h to jvmti_common.hpp
>
>
On Mon, 4 Mar 2024 03:26:58 GMT, David Holmes wrote:
>> Serguei Spitsyn has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> rename after merge: jvmti_common.h to jvmti_common.hpp
>
>
On Mon, 4 Mar 2024 03:29:01 GMT, David Holmes wrote:
>> Serguei Spitsyn has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> rename after merge: jvmti_common.h to jvmti_common.hpp
>
>
On Mon, 4 Mar 2024 03:41:55 GMT, David Holmes wrote:
>> Serguei Spitsyn has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> rename after merge: jvmti_common.h to jvmti_common.hpp
>
>
On Mon, 4 Mar 2024 03:20:41 GMT, David Holmes wrote:
>> Serguei Spitsyn has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> rename after merge: jvmti_common.h to jvmti_common.hpp
>
> src/hotspot/share/prims/jvmtiEnvBase.cpp line 1505:
>
>>
On Mon, 4 Mar 2024 03:07:58 GMT, David Holmes wrote:
>> Serguei Spitsyn has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> rename after merge: jvmti_common.h to jvmti_common.hpp
>
> src/hotspot/share/prims/jvmtiEnvBase.cpp line 1489:
>
>>
On Mon, 4 Mar 2024 07:06:31 GMT, David Holmes wrote:
>> Serguei Spitsyn has updated the pull request with a new target base due to a
>> merge or a rebase. The incremental webrev excludes the unrelated changes
>> brought in by the merge/rebase. The pull request contains four additional
>>
On Mon, 4 Mar 2024 04:09:35 GMT, David Holmes wrote:
>> src/hotspot/share/runtime/javaThread.cpp line 594:
>>
>>> 592: // thread_oop is virtual, clear carrier thread interrupt status
>>> as well
>>> 593: java_lang_Thread::set_interrupted(threadObj(), false);
>>> 594: }
>>
>>
59 matches
Mail list logo
