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
> 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
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
>
>
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
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
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
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
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
> 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
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.
>
>
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.
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
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
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
>
>
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
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
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 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()
> 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.
>
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.
>> -
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
> 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
34 matches
Mail list logo
