JFR CPU profiler does not respect the configured sampling period

[roberttoyonaga]

Describe the issue
When running with JFR enabled, the CPU sampler produces more samples than what's specified in the configuration (.jfc) file.

The sampling rate is 'N' times the specified rate in the configuration file (.jfc). Where 'N' is the number of active threads. This creates potential redundancy and overhead that scales with the number of threads at any given time.

This is a recent change that looks like it was introduced with #8517. It seems like the intent of that PR was to give each thread it's own timer (on linux). In the implementation, when each timer expires, the SIGPROF signal is sent every time. Any thread can be stopped to handle any other thread's timer expiry SIGPROF. I am unsure of why each thread must have it's own dedicated timer.

Why does this PR (#8517) add extra sampling? Was the intention to connect each timer's expiry signal to it's respective thread? If not, why not just increase the frequency of the old itimer implementation? That would allow for a more even sample distribution. Currently, all the timers expire at roughly the same time every period so we have bursty sampling.

Steps to reproduce the issue
Please include both build steps as well as run steps
Download latest EA build https://github.com/graalvm/oracle-graalvm-ea-builds/releases

1. git clone https://github.com/roberttoyonaga/graalvm-sampling-bug.git
2. javac Reproducer.java
3. native-image --enable-monitoring=jfr --install-exit-handlers Reproducer
4. ./reproducer -XX:StartFlightRecording=settings=settings.jfc,filename=rec23.jfr
5. Inspect recording in JMC
   
   We get more samples per period than specified in the configuration (1/s)

Describe GraalVM and your environment:

• OS: [linux]
• Architecture: [AMD64]

[roberttoyonaga]

@jovanstevanovic Is this observation intentional?

[jovanstevanovic]

Hey @roberttoyonaga, valid point. I'll make sure to fix that. Also, this only happens on Linux.

[jovanstevanovic]

The fix is on the master. The issue is internally tracked as GR-54471.