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
> 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 `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 Tue, 5 Mar 2024 18:39:43 GMT, Leonid Mesnik wrote:
>> Serguei Spitsyn has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> review: added new internal function
>> JvmtiEnvBase::get_thread_or_vthread_state
>
> test/hotspot/jtreg/vmTestbase/
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.
Is the caller always a JavaT
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
JVMTI_ERROR_IN
On Wed, 28 Feb 2024 22:10:04 GMT, Chris Plummer wrote:
>> Fix numerous debug agent issues and testing deficiencies related to
>> Thread.interrupt(). As a first read you should look at the description in
>> the CR. More details in first comment below.
>>
>> Also, this PR is dependent on the fix
On Tue, 5 Mar 2024 01:48:49 GMT, Jaikiran Pai wrote:
>> Hi Jai. I think that solves all the functional requirements, but now we've
>> turned two easily understood lines of code (calling run() and
>> deleteIfExists()) into what you have above. I'm not so sure it is worth it.
>> I refer back to
On Tue, 5 Mar 2024 19:57:39 GMT, Serguei Spitsyn wrote:
> The Object.wait() throws the InterruptedException if it was interrupted.
And clears the interrupted status, just like RawMonitorWait.
-
PR Comment: https://git.openjdk.org/jdk/pull/18093#issuecomment-1979670426
On Tue, 5 Mar 2024 07:47:19 GMT, Alan Bateman wrote:
>> Thank you for sharing this, Chris. It sounds like we need to introduce a
>> mechanism to temporarily hide the JVMTI events. The question is if it is
>> worth the complexity we add with it, especially if it is used just in a
>> couple of c
On Tue, 5 Mar 2024 07:07:27 GMT, David Holmes wrote:
> I have to say that I don't understand how the behaviour of `RawMonitorWait`
> is any different to `ObjectMonitor::wait` when it comes to the use of the
> is_interrupted(true). ??? Is it simply that because we are in native code and
> we ca
> 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 Tue, 5 Mar 2024 16:49:01 GMT, Kevin Walls wrote:
>> Do you know where the subject is set? If it's set by a `doAs` call then it
>> will co-operate with `current()` no matter if SM is allowed. I tried to
>> search in the whole module and cannot find a `doAs` call. If it is also
>> through `Su
On Tue, 13 Feb 2024 02:07:54 GMT, Coleen Phillimore wrote:
>> src/hotspot/share/oops/arrayKlass.cpp line 141:
>>
>>> 139: ObjArrayKlass::allocate_objArray_klass(class_loader_data(),
>>> dim + 1, this, CHECK_NULL);
>>> 140: // use 'release' to pair with lock-free load
>>> 141:
On Thu, 8 Feb 2024 21:30:48 GMT, David Holmes 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.
>
> src/hotspot/share/classfi
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.
src/hotspot/share/classfile/
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.
Thanks for looking at this W
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.
-
Commit messages:
- 8308745: ObjArrayKlass::allocate_objArray_klass may call into j
On Tue, 5 Mar 2024 18:16:03 GMT, Leonid Mesnik wrote:
>> Serguei Spitsyn has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> review: addressed a couple of comments on new test
>
> test/hotspot/jtreg/serviceability/jvmti/vthread/InterruptRawM
looking at the "attacher" code in jdk.attach it certainly does not
appear to attempt to "attach" via cwd, so I would say that the
"attachee" code to check this is redundant, unless there is a backwards
compatibility/interoperability issue that requires this where
an early JDK "attacher" might a
On Tue, 5 Mar 2024 06:18:56 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
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 i
On Tue, 5 Mar 2024 14:44:29 GMT, Weijun Wang wrote:
>> Right, this does not depend on the SM. All we need to do is get the
>> Subject.
>> This method implements the basic monitor (readonly) and control (readwrite)
>> access.
>> accessMap maps identity String to Access, and the checkAccess() m
> 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 Tue, 5 Mar 2024 11:36:53 GMT, Kevin Walls wrote:
>> I think we need @kevinjwalls or @dfuch to help advise on this.
>
> Right, this does not depend on the SM. All we need to do is get the Subject.
> This method implements the basic monitor (readonly) and control (readwrite)
> access.
> acces
On Mon, 4 Mar 2024 22:02:53 GMT, Kevin Walls 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.
>> - jcheck
On Mon, 4 Mar 2024 19:57:25 GMT, Sean Mullan wrote:
>> I was not exactly sure if we will support this functionality when there is
>> no SM. The class name has `AccessControler` and the method names use
>> `checkAccess`, but they actually do not always depend on security manager.
>
> I think we
> 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
> 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, 5 Mar 2024 08:48:15 GMT, Martin Doerr wrote:
>> Suchismith Roy has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> indendt
>
> jdk21u is only open for critical backports and requires special approval.
> Please backport it to jdk21u-
> 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, 5 Mar 2024 08:53:42 GMT, Serguei Spitsyn wrote:
>> src/hotspot/share/prims/jvmtiEnvBase.cpp line 1507:
>>
>>> 1505: nWait = 0;
>>> 1506: for (ObjectWaiter* waiter = mon->first_waiter();
>>> 1507: waiter != nullptr && (nWait == 0 || waiter !=
>>> mon->first_waiter());
>>
On Tue, 5 Mar 2024 06:30:20 GMT, David Holmes wrote:
>> Serguei Spitsyn has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> review: addressed more comments on the fix and new test
>
> src/hotspot/share/prims/jvmtiEnvBase.cpp line 1507:
>
>>
On Tue, 27 Feb 2024 08:31:15 GMT, Suchismith Roy wrote:
>> J2SE agent does not start and throws error when it tries to find the shared
>> library ibm_16_am.
>> After searching for ibm_16_am.so ,the jvm agent throws and error as dll_load
>> fails.It fails to identify the shared library ibm_16_am
34 matches
Mail list logo
