RFR: 8220657: JFR.dump does not work when filename is set

[Erik Gahlin]

Yes, but then you would lose the original destination in other scenarios

Maybe I can look at this next week.

Erik

> Hi Erik,
>
> Thank you for your reply.
>
> How about this changeset?
>
>   http://cr.openjdk.java.net/~ysuenaga/JDK-8220657/webrev.01/
>
> I think PlatformRecording#newSnapshotClone() should not dump.
> So I removed `setDestination()` from this.
>
>
> Yasumasa
>
>
> On 2019/03/19 22:04, Erik Gahlin wrote:
>> This looks a bit hackish.
>>
>> The real issue seems to be that the method
>> PlatformRecording#newSnapshotClone incorrectly sets the destination in
>> the clone, which then triggers a dump prematurely (when stop is called).
>>
>> Purpose of that method is just to take a snapshot of existing chunks in
>> the disk repository (or from memory). and then let dumpStopped(path) do
>> the actual dump (copy out the data from the disk repository).
>>
>> To make it work, some other changes would be needed as well, but I don't
>> have time to investigate.
>>
>> Erik
>>
>>> Hi all,
>>>
>>> Please review this change.
>>>
>>>     JBS: https://bugs.openjdk.java.net/browse/JDK-8220657
>>>     webrev: http://cr.openjdk.java.net/~ysuenaga/JDK-8220657/webrev.00/
>>>
>>> The user might not get flight record via JFR.dump if JFR is started
>>> with filename option on target process.
>>>
>>> Please see JBS if you want to know how to reproduce.
>>>
>>>
>>> Thanks,
>>>
>>> Yasumasa