On Wed, 15 May 2024 06:00:46 GMT, Serguei Spitsyn wrote:
>> I'm not sure this answered Chris' query properly. Or I'm reading Chris'
>> query wrong.
>>
>> Perhaps this is not what Chris had in mind, but I'm wondering what happens
>> in some
>> Thread-A when it is checked and passed by but then
On Fri, 10 May 2024 22:09:01 GMT, Daniel D. Daugherty
wrote:
> Perhaps this is not what Chris had in mind, but I'm wondering what happens in
> some
> Thread-A when it is checked and passed by but then Thread-A sets the flag in
> itself
> after the for-loop has passed it by. Does that Thread-A
On Tue, 30 Apr 2024 01:49:31 GMT, Serguei Spitsyn wrote:
>> src/hotspot/share/prims/jvmtiThreadState.cpp line 366:
>>
>>> 364: attempts--;
>>> 365: }
>>> 366: DEBUG_ONLY(if (attempts == 0) break;)
>>
>> Previously `_VTMS_transition_count` considered all threads at the
On Tue, 30 Apr 2024 01:56:13 GMT, Serguei Spitsyn wrote:
>> This is a fix of the following JVMTI scalability issue. A closed benchmark
>> with millions of virtual threads shows 3X-4X overhead when a JVMTI agent has
>> been loaded. For instance, this is observable when an app is executed under
On Tue, 30 Apr 2024 01:56:13 GMT, Serguei Spitsyn wrote:
>> This is a fix of the following JVMTI scalability issue. A closed benchmark
>> with millions of virtual threads shows 3X-4X overhead when a JVMTI agent has
>> been loaded. For instance, this is observable when an app is executed under
On Tue, 30 Apr 2024 01:56:13 GMT, Serguei Spitsyn wrote:
>> This is a fix of the following JVMTI scalability issue. A closed benchmark
>> with millions of virtual threads shows 3X-4X overhead when a JVMTI agent has
>> been loaded. For instance, this is observable when an app is executed under
> This is a fix of the following JVMTI scalability issue. A closed benchmark
> with millions of virtual threads shows 3X-4X overhead when a JVMTI agent has
> been loaded. For instance, this is observable when an app is executed under
> control of the Oracle Studio `collect` utility.
> For perfor
On Fri, 26 Apr 2024 19:34:55 GMT, Chris Plummer wrote:
>> Serguei Spitsyn has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> review: fixed minor issues: renamed function, corrected comment, removed
>> typo in assert
>
> src/hotspot/share/p
On Fri, 26 Apr 2024 19:38:40 GMT, Chris Plummer wrote:
>> Serguei Spitsyn has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> review: fixed minor issues: renamed function, corrected comment, removed
>> typo in assert
>
> src/hotspot/share/p
On Fri, 26 Apr 2024 07:45:50 GMT, Serguei Spitsyn wrote:
>> This is a fix of the following JVMTI scalability issue. A closed benchmark
>> with millions of virtual threads shows 3X-4X overhead when a JVMTI agent has
>> been loaded. For instance, this is observable when an app is executed under
> This is a fix of the following JVMTI scalability issue. A closed benchmark
> with millions of virtual threads shows 3X-4X overhead when a JVMTI agent has
> been loaded. For instance, this is observable when an app is executed under
> control of the Oracle Studio `collect` utility.
> For perfor
On Thu, 25 Apr 2024 20:39:03 GMT, Alex Menkov wrote:
>> This is a fix of the following JVMTI scalability issue. A closed benchmark
>> with millions of virtual threads shows 3X-4X overhead when a JVMTI agent has
>> been loaded. For instance, this is observable when an app is executed under
>> c
On Wed, 24 Apr 2024 16:04:30 GMT, Serguei Spitsyn wrote:
> This is a fix of the following JVMTI scalability issue. A closed benchmark
> with millions of virtual threads shows 3X-4X overhead when a JVMTI agent has
> been loaded. For instance, this is observable when an app is executed under
> c
On Wed, 24 Apr 2024 16:04:30 GMT, Serguei Spitsyn wrote:
> This is a fix of the following JVMTI scalability issue. A closed benchmark
> with millions of virtual threads shows 3X-4X overhead when a JVMTI agent has
> been loaded. For instance, this is observable when an app is executed under
> c
This is a fix of the following JVMTI scalability issue. A closed benchmark with
millions of virtual threads shows 4X overhead when a JVMTI agent has been
loaded. For instance, this is observable when an app is executed under control
of the Oracle Studio `collect` utility.
The benchmark takes a
15 matches
Mail list logo
