RFR: 8241678: Remove PerfData sampling via StatSampler [v4]

[Kevin Walls]

On Thu, 22 May 2025 14:09:37 GMT, Casper Norrbin <cnorrbin at openjdk.org> wrote:

>> Hi everyone,
>> 
>> This change removes the legacy `PerfData` sampling mechanism implemented through the `StatSampler` — an always-on periodic task that runs every 50ms my default. The sampling feature was originally introduced to collect performance counters and timestamps, but has since seen very little use.
>> 
>> For G1/ZGC, the only sampled value is a timestamp (`sun.os.hrt.ticks`). For Serial/Parallel, it also samples some heap space counters, but these are already updated after each GC cycle, making the sampling redundant. With sampling removed, the `PerfDataSamplingInterval` flag becomes obsoleted, as it no longer serves any purpose.
>> 
>> The only thing relying on the sampled timestamps is `jstat`: running `jstat -t` prints an extra column with the time since VM start. To preserve this funcitonality, we can calculate the timestamps as an offset from the already existing `sun.rt.createVmBeginTime` instead.
>
> Casper Norrbin has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains seven commits:
> 
>  - Merge branch 'master' into statsampler-removal
>  - removed last traces of hrt.ticks
>  - Merge branch 'master' into statsampler-removal
>  - feedback fixes
>  - removed the PerfDataSamplingInterval flag
>  - calculate timestamp in jstat instead of sampling
>  - StatSampler + sampling code removed

Hi, looks good.
If we are removing things from jcmd PerfCounter.print output, that could feature in the release note that you have planned.  Anybody expecting these counters using jcmd PerfCounter.print or other methods, may not know that they are related to StatSampler and would not realise from the title that this is a relevant change.

$ jcmd 203133 PerfCounter.print | grep hrt
sun.os.hrt.frequency=1000000000
sun.os.hrt.ticks=132389861230

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24872#issuecomment-2915558106