On Tue, 15 Nov 2022 18:52:37 GMT, Coleen Phillimore wrote:
>> The JVM code took a ThreadGroup lock before poking into ThreadGroup fields.
>> Call a method in the ThreadGroup to call the synchronized method instead.
>> Tested with tier 1-4.
>
> Coleen Phillimore has updated the pull request incr
On Tue, 15 Nov 2022 18:52:37 GMT, Coleen Phillimore wrote:
>> The JVM code took a ThreadGroup lock before poking into ThreadGroup fields.
>> Call a method in the ThreadGroup to call the synchronized method instead.
>> Tested with tier 1-4.
>
> Coleen Phillimore has updated the pull request incr
On Tue, 15 Nov 2022 18:52:37 GMT, Coleen Phillimore wrote:
>> The JVM code took a ThreadGroup lock before poking into ThreadGroup fields.
>> Call a method in the ThreadGroup to call the synchronized method instead.
>> Tested with tier 1-4.
>
> Coleen Phillimore has updated the pull request incr
On Tue, 15 Nov 2022 18:52:37 GMT, Coleen Phillimore wrote:
>> The JVM code took a ThreadGroup lock before poking into ThreadGroup fields.
>> Call a method in the ThreadGroup to call the synchronized method instead.
>> Tested with tier 1-4.
>
> Coleen Phillimore has updated the pull request incr
On Wed, 16 Nov 2022 03:54:31 GMT, Serguei Spitsyn wrote:
>> Coleen Phillimore has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Review comments.
>
> src/hotspot/share/prims/jvmtiEnvBase.cpp line 564:
>
>> 562:
>> 563: for (int i = 0; i
On Tue, 15 Nov 2022 18:52:37 GMT, Coleen Phillimore wrote:
>> The JVM code took a ThreadGroup lock before poking into ThreadGroup fields.
>> Call a method in the ThreadGroup to call the synchronized method instead.
>> Tested with tier 1-4.
>
> Coleen Phillimore has updated the pull request incr
On Wed, 9 Nov 2022 09:19:33 GMT, Serguei Spitsyn wrote:
>> Coleen Phillimore has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Forgot a null check.
>
> src/hotspot/share/prims/jvmtiEnvBase.cpp line 564:
>
>> 562:
>> 563: for (int i=0;
On Wed, 9 Nov 2022 11:54:55 GMT, Serguei Spitsyn wrote:
>> I don't think this has changed. Right now, if there are no child subgroups
>> then *group_count_ptr will be 0 and *groups_ptr will be NULL as there is no
>> memory to deallocate. JVMTI Deallocate is specified to do nothing when
>> call
On Tue, 8 Nov 2022 23:35:47 GMT, David Holmes wrote:
>> Coleen Phillimore has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Forgot a null check.
>
> src/hotspot/share/prims/jvmtiEnvBase.cpp line 540:
>
>> 538:
>> 539: jthread *
>> 540: J
> The JVM code took a ThreadGroup lock before poking into ThreadGroup fields.
> Call a method in the ThreadGroup to call the synchronized method instead.
> Tested with tier 1-4.
Coleen Phillimore has updated the pull request incrementally with one
additional commit since the last revision:
R
On Wed, 9 Nov 2022 09:49:10 GMT, Alan Bateman wrote:
>> src/hotspot/share/prims/jvmtiEnvBase.cpp line 557:
>>
>>> 555: JvmtiEnvBase::new_jthreadGroupArray(int length, objArrayHandle groups)
>>> {
>>> 556: if (length == 0) {
>>> 557: return NULL;
>>
>> I do not think returning NULL is all
On Wed, 9 Nov 2022 09:32:42 GMT, Serguei Spitsyn wrote:
>> Coleen Phillimore has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Forgot a null check.
>
> src/hotspot/share/prims/jvmtiEnvBase.cpp line 557:
>
>> 555: JvmtiEnvBase::new_jthread
On Tue, 8 Nov 2022 14:55:17 GMT, Coleen Phillimore wrote:
>> The JVM code took a ThreadGroup lock before poking into ThreadGroup fields.
>> Call a method in the ThreadGroup to call the synchronized method instead.
>> Tested with tier 1-4.
>
> Coleen Phillimore has updated the pull request incre
On Tue, 8 Nov 2022 14:55:17 GMT, Coleen Phillimore wrote:
>> The JVM code took a ThreadGroup lock before poking into ThreadGroup fields.
>> Call a method in the ThreadGroup to call the synchronized method instead.
>> Tested with tier 1-4.
>
> Coleen Phillimore has updated the pull request incre
On Tue, 8 Nov 2022 14:55:17 GMT, Coleen Phillimore wrote:
>> The JVM code took a ThreadGroup lock before poking into ThreadGroup fields.
>> Call a method in the ThreadGroup to call the synchronized method instead.
>> Tested with tier 1-4.
>
> Coleen Phillimore has updated the pull request incre
> The JVM code took a ThreadGroup lock before poking into ThreadGroup fields.
> Call a method in the ThreadGroup to call the synchronized method instead.
> Tested with tier 1-4.
Coleen Phillimore has updated the pull request incrementally with one
additional commit since the last revision:
C
On Tue, 8 Nov 2022 12:47:29 GMT, Alan Bateman wrote:
>> Coleen Phillimore has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Handle non OOM exceptions and rename subgroupsAsArray.
>
> I wonder if the intermediate resource array is needed no
> The JVM code took a ThreadGroup lock before poking into ThreadGroup fields.
> Call a method in the ThreadGroup to call the synchronized method instead.
> Tested with tier 1-4.
Coleen Phillimore has updated the pull request incrementally with one
additional commit since the last revision:
F
On Tue, 8 Nov 2022 13:06:50 GMT, Coleen Phillimore wrote:
>> The JVM code took a ThreadGroup lock before poking into ThreadGroup fields.
>> Call a method in the ThreadGroup to call the synchronized method instead.
>> Tested with tier 1-4.
>
> Coleen Phillimore has updated the pull request incre
On Tue, 8 Nov 2022 12:48:01 GMT, Alan Bateman wrote:
>> Coleen Phillimore has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Handle non OOM exceptions and rename subgroupsAsArray.
>
> src/java.base/share/classes/java/lang/ThreadGroup.java l
> The JVM code took a ThreadGroup lock before poking into ThreadGroup fields.
> Call a method in the ThreadGroup to call the synchronized method instead.
> Tested with tier 1-4.
Coleen Phillimore has updated the pull request incrementally with one
additional commit since the last revision:
f
On Tue, 8 Nov 2022 12:30:37 GMT, Coleen Phillimore wrote:
>> The JVM code took a ThreadGroup lock before poking into ThreadGroup fields.
>> Call a method in the ThreadGroup to call the synchronized method instead.
>> Tested with tier 1-4.
>
> Coleen Phillimore has updated the pull request incre
On Tue, 8 Nov 2022 04:35:48 GMT, David Holmes wrote:
>> Coleen Phillimore has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Handle non OOM exceptions and rename subgroupsAsArray.
>
> src/hotspot/share/prims/jvmtiEnvBase.cpp line 810:
>
>>
> The JVM code took a ThreadGroup lock before poking into ThreadGroup fields.
> Call a method in the ThreadGroup to call the synchronized method instead.
> Tested with tier 1-4.
Coleen Phillimore has updated the pull request incrementally with one
additional commit since the last revision:
H
On Tue, 8 Nov 2022 00:58:44 GMT, Coleen Phillimore wrote:
> The JVM code took a ThreadGroup lock before poking into ThreadGroup fields.
> Call a method in the ThreadGroup to call the synchronized method instead.
> Tested with tier 1-4.
Thanks Alan for your comment - yes, I think doing upcalls
On Tue, 8 Nov 2022 10:05:34 GMT, Alan Bateman wrote:
>> The JVM code took a ThreadGroup lock before poking into ThreadGroup fields.
>> Call a method in the ThreadGroup to call the synchronized method instead.
>> Tested with tier 1-4.
>
> src/java.base/share/classes/java/lang/ThreadGroup.java li
On Tue, 8 Nov 2022 00:58:44 GMT, Coleen Phillimore wrote:
> The JVM code took a ThreadGroup lock before poking into ThreadGroup fields.
> Call a method in the ThreadGroup to call the synchronized method instead.
> Tested with tier 1-4.
src/java.base/share/classes/java/lang/ThreadGroup.java lin
On Tue, 8 Nov 2022 04:45:17 GMT, David Holmes wrote:
> This is a nice simplification of the VM side of the code! I do have to wonder
> why this was implemented the way it was rather than doing the simple upcall
> as you now do, but I suspect it was just performance,
I don't think JVMTI GetThre
On Tue, 8 Nov 2022 00:58:44 GMT, Coleen Phillimore wrote:
> The JVM code took a ThreadGroup lock before poking into ThreadGroup fields.
> Call a method in the ThreadGroup to call the synchronized method instead.
> Tested with tier 1-4.
This looks nice in general.
But I will make another pass.
On Tue, 8 Nov 2022 00:58:44 GMT, Coleen Phillimore wrote:
> The JVM code took a ThreadGroup lock before poking into ThreadGroup fields.
> Call a method in the ThreadGroup to call the synchronized method instead.
> Tested with tier 1-4.
This is a nice simplification of the VM side of the code!
The JVM code took a ThreadGroup lock before poking into ThreadGroup fields.
Call a method in the ThreadGroup to call the synchronized method instead.
Tested with tier 1-4.
-
Commit messages:
- 8296492: Remove ObjectLocker in JVMTI get_subgroups call
Changes: https://git.openjdk.or
31 matches
Mail list logo
