When JFR was open sourced, the method of generating JFR files for native events was changed from XSLT transforms to a simple Java program. This made the generation process faster and much more easy to read and maintain.

However, the generated C++ files from the Java program looks exactly like the ones generated by the XSLT transforms, down to white spaces and line breaks.This was done to make it easy to diff the two versions and avoid regressions that would complicate the open sourcing effort.

Now that JFR has worked fine for two releases in OpenJDK, it is time to clean up and simplify the generated C++ files. There is legacy due to XSLT and how JFR was implemented 5 years ago.

Some ideas:

- Remove jfrEventIds.hpp and instead add the event Id to the Event classes, next to isRequestable, hasThread and other constants.

- Remove jfrTypes.hpp and obsolete (native) content type types, such as TYPE_BYTES., TYPE_NANOS etc. and unneeded dummy types (TYPE_DUMMY, TYPE_DUMMY_1). It may be possible to move the id into the JfrStructs and avoid the JfrTypeId enum all together. The ReservedEvent enum doesn't have to be in generated code and could be removed at the same time.

- Remove jfrPeriodic.hpp and move switch statements into jfrEventClasses.hpp. Perhaps use a static method on every event class instead and remove TRACE_REQUEST_FUNC macro in jfrPeriodic.cpp. This could allow periodic event hooks to be defined in the subsystem where they are being used.

- Remove jfEventControl.hpp and move array into jfrEventClasses.hpp

- Call the Java program with INCLUDE_JFR and generate the approriate event bodies etc. and avoid the duplication and #ifndef in the generated code.

This means we will end up with one single (smaller?) generated JFR file. We should also update metadata.xml and provide documentation where the logic for generating the jfr file is located (in the source code tree) and where the generated output file can be found.