On Fri, 8 Mar 2024 06:17:06 GMT, David Holmes wrote:
>> Coleen Phillimore has updated the pull request incrementally with two
>> additional commits since the last revision:
>>
>> - Missed a word.
>> - David's comment fixes.
>
> src/hotspot/share/prims/jvmtiGetLoadedClasses.cpp line 121:
>
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
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
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
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
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
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
> 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
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
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
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
On Thu, 7 Mar 2024 00:54:30 GMT, David Holmes wrote:
>> OK. It's a good thing HotSpot doesn't need to worry about
>> priority-inheritance for mutexes.
>
> 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
On Thu, 7 Mar 2024 00:18:53 GMT, Dean Long wrote:
>> Coleen Phillimore has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Dean's comments.
>
> src/hotspot/share/oops/arrayKlass.cpp line 135:
>
>> 133: ResourceMark rm(THREAD);
>> 134:
On Thu, 7 Mar 2024 01:35:45 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
> 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 one
additional
On Thu, 7 Mar 2024 00:16:39 GMT, Dean Long wrote:
>> Semaphore seemed simpler (?)
>
> OK. It's a good thing HotSpot doesn't need to worry about
> priority-inheritance for mutexes.
Semaphore seems simpler/cleaner and ready to use.
-
PR Review Comment:
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.
Marked as reviewed by dlong
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.
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.
On Wed, 6 Mar 2024 23:47:01 GMT, Coleen Phillimore wrote:
>> src/hotspot/share/runtime/mutex.cpp line 537:
>>
>>> 535: // can be called by jvmti by VMThread.
>>> 536: if (current->is_Java_thread()) {
>>> 537: _sem.wait_with_safepoint_check(JavaThread::cast(current));
>>
>> Why
On Wed, 6 Mar 2024 23:09:34 GMT, Dean Long 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.
>
>
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.
OK, that makes sense about
On Tue, 5 Mar 2024 23:13:30 GMT, Dean Long 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 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
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, 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 Thu, 1 Feb 2024 05:22:24 GMT, David Holmes wrote:
>> This change uses a claim token to allocate multi dimensional arrays rather
>> than holding MultiArray_lock around metaspace allocation. We can't hold a
>> mutex around metaspace allocation because it can create an OOM object and it
>>
On Wed, 31 Jan 2024 18:57:23 GMT, Coleen Phillimore wrote:
> This change uses a claim token to allocate multi dimensional arrays rather
> than holding MultiArray_lock around metaspace allocation. We can't hold a
> mutex around metaspace allocation because it can create an OOM object and it
>
This change uses a claim token to allocate multi dimensional arrays rather than
holding MultiArray_lock around metaspace allocation. We can't hold a mutex
around metaspace allocation because it can create an OOM object and it can also
call into JVMTI for a resource exhausted event. Also, we
33 matches
Mail list logo
