RFR: 6988: Initial implementation of JFR binary format writer [v6]

[Alexander Kuznetsov]

On Thu, 14 Jan 2021 17:22:40 GMT, Marcus Hirt <hirt at openjdk.org> wrote:

>> Hi! We at JetBrains tried to use this writer to make tests for our JMC fork support. It works fine, however, it seems that almost every type is assumed to have constant pool (`org.openjdk.jmc.flightrecorder.writer.ConstantPool#writeValueType`). But that’s not always true; for example, async-profiler and JFR write `jdk.types.StackFrame` as-is, not referring to constant pool. It may lead to false-positive/negative outcomes when generated recordings are parsed well while the real ones make parser fail, or vice versa.
>> Is it worth to extend API to control which types must have constant pool and which must not? What do you think?
>
> Hi @AlexVanGogen! I think that is a great idea - that said, we're very close to the next source release. I was just about to approve this. How would you like the API to look/work?

Since this PR is ready for approval, and what I've proposed is not critical, maybe it will be better to create a separate issue for that?
What about API – I don't know what is the best way to tell we want this type (not) to have a constant pool; currently investigating. Internally, I believe there are two places responsible – `org.openjdk.jmc.flightrecorder.writer.MetadataImpl#createCustomType` (will the type have a constant pool) and aforementioned `org.openjdk.jmc.flightrecorder.writer.ConstantPool#writeValueType` (will the value be written as a reference to a constant pool).

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

PR: https://git.openjdk.java.net/jmc/pull/84