RFR: 7264: Improve the performance of the JFR parser

[Erik Gahlin]

On Mon, 14 Jun 2021 08:10:46 GMT, Jean-Philippe Bempel <jpbempel at openjdk.org> wrote:

> When parsing a JFR file, StackFrames are the objects that are the most
> deserialized using Readers.
> By default, JMC core parser used a generic ReflectiveReaders
> which use reflection to parser the structure. However, we have known
> objects like stack frames where we could directly map to the typed
> object instead on relying on reflection, which speed up significantly
> the parsing.
> 
> Here the results for c5.2xlarge instance single threaded parsing with 24MB jfr recording with 100 iterations:
> 
> | runs | baseline | specific readers optim | improvement |
> | --- | --- | --- | --- |
> | run 1 | 54,317ms | 39,623ms | -27% |
> | run 2 | 54,988ms | 39,520ms | -28% |
> | run 3 | 54,209ms | 39,904ms | -26% |

I never thought reflection was a good idea, and It makes sense to have specialised logic for known types, but I don't think the code should rely on the field order.

In earlier release of JMC (4.1), there was similar specialiced logic as yours, but it broke once the "truncated" field was added to the stack trace struct in JDK 7. The same thing can happen again. 

Back then, there was a field accessor class where the index was looked up when the parser was created. When the value was read the accessor could use the pre-calculated index to get the correct value. It might even have been bytecode generated for optimal performance.

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

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