# Steps to reproduce the behavior:

1. Download JDK 8u312 from https://github.com/adoptium/temurin8-binaries/releases/download/jdk8u312-b07/OpenJDK8U-jdk_x64_windows_hotspot_8u312b07.msi
2. Install the download JDK and set the PATH appropriately
3. Download the Renaissance benchmark from https://github.com/renaissance-benchmarks/renaissance/releases/download/v0.13.0/renaissance-mit-0.13.0.jar
4, Go to the location where the renaissance-mit-0.13.0.jar is saved
5. Run the benchmark without JFR to obtain the base timings
`java -Xms1024M -Xmx1024M -Xrs -XX:+UseG1GC -jar .\renaissance-mit-0.13.0.jar -r 2 finagle-chirper`
and note down the time it took to finish the iterations
6. Now run the benchmark with the JFR recording started
`java "-XX:StartFlightRecording=duration=240s,settings=profile,filename=profile.jfr,disk=true" "-XX:FlightRecorderOptions=repository=JFR" -Xms1024M -Xmx1024M -Xrs -XX:+UseG1GC -jar .\renaissance-mit-0.13.0.jar -r 2 finagle-chirper`
and note down the iteration times


# Expected behavior

The iteration times with JFR recording started should be only slightly higher than the base time (a few percents at most).
However, the observed difference is around 2x which is unexpected.

# Additional context

This is windows specific issue. The same JDK 8u312 build running eg. on Linux or Mac does not exhibit this performance degradation. Also, the performance degradation is not observable with JDK 11 or later on the same test machine.
As per my investigation the overhead is caused by the JFR thread sampling - once I disabled `jdk.NativeMethodSample` and `jdk.ExecutionSample` JFR events the overhead completely disappeared. This would indicate that the offending part is actually obtaining the thread stack trace.