RFR: 7855: JFR Writer incorrectly uses epoch nanoseconds as the start ticks [v3]

[Jaroslav Bachorik]

On Thu, 6 Oct 2022 08:28:28 GMT, Jaroslav Bachorik <jbachorik at openjdk.org> wrote:

>> Currently, the JFR recordings created by the JMC writer will have the start ticks set to the same value as the start timestamp. This will cause problems with the duration calculation which is using directly `System.nanoTime()` and as such the resulting value will be rather nonsensical.
>> 
>> This PR adds two new recording settings - `startTicks` and `duration` which can be used to write a JFR recording with correct values set. If the user does not set those settings `startTicks` will be set to the value of `System.nanoTime()` at the moment the recording is started (a `Recording` instance is created) and `duration` will be computed as a diff between the current value of `System.nanoTime()` and `startTicks`.
>
> Jaroslav Bachorik has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Outstanding 'duration' fixes and cleanup
>  - Update and formalize new jfr.writer dependencies

Hi Christoph,

Regarding the varint signedness - it is a bit of grey area. The encoding used in JFR and this writer impl is not preserving sign - but, IMO, it should be possible to write a Java long number in its entirety such that when I write out -1 and read it back to Java I would get -1, although it is really treated as `0xffffffffffffffff` by the writer/parser. 
But changing that behaviour would require changes in JFR and JMC as in both places the number of bytes comprising a long number is limited to 9.

Regarding the usage - we are not using the writer in the JMC project yet. However, we are using it at Datadog to generate 'on-the-fly' recordings for tests where we can create really exotic combinations of events to make sure our backend can deal with them.

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

PR: https://git.openjdk.org/jmc/pull/412