RFR: 8370715: JFR: Races are possible when dumping recordings [v3]

[Erik Gahlin]

On Wed, 26 Nov 2025 17:51:02 GMT, Robert Toyonaga <duke at openjdk.org> wrote:

>> #### Summary
>> This PR changes the JFR snapshot dumping code so that multiple JFR recordings (potentially from different processes) racing to write the same dump destination won't mix their data. 
>> 
>> #### Problem
>> The dump destination file is created and/or wiped when a recording is started, but not wiped again before actually copying over the chunks during a dump. So in the window of time between creating/wiping and dumping chunks, another recording could write to the same dump destination and have it's chunks added to the snapshot. This can happen with either a single JVM or multiple JVMs that are racing.
>> 
>> #### Proposed fix
>> This PR ensures that any data previously written to the dump destination is wiped before the new recording's data is written.  File locking is also done while chunks are being written. 
>> 
>> Testing:
>> - new test `jdk/jdk/jfr/api/recording/dump/TestDumpOverwrite.java`
>> - Tier 1
>
> Robert Toyonaga has updated the pull request incrementally with one additional commit since the last revision:
> 
>   vm.flagless and fix copyright header

Looks good, but I wonder if LogLevel.INFO should be used instead of WARN, similar to the Transferred bytes log entry? 

The fix now ensures that dump files are in a consistent state, which is good, but I'm not sure writing a file simultaneously should constitute a warning. If the process overwrites a file 1 ns before or 1 ns after the lock, a warning is not issued. In all cases, one of the files be overwritten (since that is what the user has requested). This isn't a major concern for me since it's unlikely to occur in practice, so I'm not insisting on a fix.

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

PR Comment: https://git.openjdk.org/jdk/pull/28460#issuecomment-3602058130