On Mon, 4 Dec 2023 13:07:15 GMT, Stefan Johansson wrote:
>> In the interest of the RDP1 deadline, should we leave improving the sync
>> issues with gc_total to a separate RFE? (Especially given that a "correct"
>> design may take some time to come up with, and that gc_total being slightly
>> o
On Fri, 1 Dec 2023 22:37:58 GMT, Jonathan Joo wrote:
>> I think the ideal approach to simplify this is to support Atomic operation
>> on a `PerfCounter`.
>> We could either introduce a `PerfAtomicCounter`/`PerfAtomicLongCounter`
>> class, or perform `Atomic::add()` on the `PerfData::_valuep` po
On Fri, 1 Dec 2023 21:01:29 GMT, Man Cao wrote:
>> I agree that the counter is valuable if always up-to-date, but if it is out
>> of sync compared to the "concurrent counters" I think it will confuse some
>> users. So if we want to keep it I think we should try to keep it in sync.
>>
>> I sup
On Fri, 1 Dec 2023 10:21:31 GMT, Stefan Johansson wrote:
>> Right, see @simonis 's comments at
>> https://github.com/openjdk/jdk/pull/15082#pullrequestreview-1613868256,
>> https://github.com/openjdk/jdk/pull/15082#discussion_r1321703912.
>>
>> I initially had similar thought that `gc_total` i
On Thu, 30 Nov 2023 21:43:36 GMT, Man Cao wrote:
>> @simonis was the original suggester of this counter, so I will defer to his
>> expertise. I do agree that dropping the counter would simplify things, but
>> it also might not hurt to just leave it in. I'm okay with either option!
>
> Right, se
On Thu, 30 Nov 2023 21:17:14 GMT, Jonathan Joo wrote:
>> Me and Albert just spoke and we do see the problem that two concurrent
>> threads could be executing the closure at the same time. So if having a
>> total counter we need to sync the updates. But when talking we started to
>> question ho
On Thu, 30 Nov 2023 09:30:14 GMT, Stefan Johansson wrote:
>> Both `publish_gc_total_cpu_time` and `~ThreadTotalCPUTimeClosure` are called
>> by the vm-thread inside a safepoint, so there shouldn't be any other threads
>> running simultaneously, I believe.
>
> Me and Albert just spoke and we do
On Thu, 30 Nov 2023 06:45:02 GMT, Albert Mingkun Yang wrote:
>> I agree that in the case that multiple closures are not active at the same
>> time, we wouldn't have to implement it in this way. However, isn't it
>> possible to have multiple closures active simultaneously, e.g. vm thread,
>> c
On Thu, 30 Nov 2023 02:39:39 GMT, Jonathan Joo wrote:
>> This two-step update does seem unnecessary, IMO.
>
> I agree that in the case that multiple closures are not active at the same
> time, we wouldn't have to implement it in this way. However, isn't it
> possible to have multiple closures a
On Wed, 29 Nov 2023 15:24:52 GMT, Albert Mingkun Yang wrote:
>> src/hotspot/share/runtime/cpuTimeCounters.cpp line 91:
>>
>>> 89: } while (old_value != fetched_value);
>>> 90: get_counter(CPUTimeGroups::CPUTimeType::gc_total)->inc(fetched_value);
>>> 91: }
>>
>> Why do we have to do this pu
On Wed, 29 Nov 2023 08:24:22 GMT, Stefan Johansson wrote:
>> Jonathan Joo has updated the pull request incrementally with two additional
>> commits since the last revision:
>>
>> - Fix namespace issues (2)
>>
>>Co-authored-by: Stefan Johansson
>> <54407259+kstef...@users.noreply.githu
On Tue, 28 Nov 2023 02:22:45 GMT, Jonathan Joo wrote:
>> 8315149: Add hsperf counters for CPU time of internal GC threads
>
> Jonathan Joo has updated the pull request incrementally with two additional
> commits since the last revision:
>
> - Fix namespace issues (2)
>
>Co-authored-by:
> 8315149: Add hsperf counters for CPU time of internal GC threads
Jonathan Joo has updated the pull request incrementally with two additional
commits since the last revision:
- Fix namespace issues (2)
Co-authored-by: Stefan Johansson <54407259+kstef...@users.noreply.github.com>
- Fix
13 matches
Mail list logo
