RFR: 8365066: RecordingStream and RemoteRecordingStream do not terminate when the associated Recording is stopped or closed externally

[Chihiro Ito]

On Thu, 21 Aug 2025 18:12:46 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

>> Did you look into adding a FlightRecorderListener and implementing recordingStateChanged to check if the RecordingState is CLOSED and then call close() on the stream? Or perhaps it would be better to set a flag and let the thread running the stream close itself after the next flush is complete.
>> 
>> For a RemoteRecordingStream there is a JMX notification that can be listened on.
>
>> @egahlin Could you please review this please? I added a listener-based mechanism that propagates external stop/close to the stream.
> 
> This will take me some time to go through. I'm a little bit worried about the locking, but I need to investigate, before I can comment further.

@egahlin 

I apologize.
I forgot to fix some code I had been using to test the locking behavior and mistakenly committed it.
I’ll correct this and push the changes soon.

I do have one question: is there a general preference between using synchronized and ReentrantLock?
Personally, I lean toward ReentrantLock, since it can be safely used with virtual threads and may be easier to backport if needed.

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

PR Comment: https://git.openjdk.org/jdk/pull/26710#issuecomment-3217745957