RFR: 8330677: Add Per-Compilation memory usage to JFR [v2]

[Thomas Stuefe]

On Fri, 26 Apr 2024 12:40:00 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> We have the (opt-in, disabled by default) compiler memory statistics introduced with [JDK-8317683](https://bugs.openjdk.org/browse/JDK-8317683).
>> 
>> Since temporary memory usage by compilers can significantly affect process footprint, it would make sense to expose at least the total peak usage per compilation via JFR.
>> 
>> --- 
>> 
>> This patch adds "Arena Usage" to CompilationEvent. We now see in JMC how costly a compilation had been. (The cost can get very high, as we have seen just recently again with [JDK-8327247](https://bugs.openjdk.org/browse/JDK-8327247) ).
>> 
>> ![jmc-memstat](https://github.com/openjdk/jdk/assets/6041414/8cac366a-2a8f-45ca-be40-d419712f81a7)
>
> Thomas Stuefe has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains three commits:
> 
>  - Adapt test
>  - merge
>  - JDK-8330677-Add-Per-Compilation-memory-usage-to-JFR

> > I read through the comments twice and did not find a nullptr related question. Which question?
> 
> See compilationMemoryStatistic.cpp .
> 
> At some places we check the result for nullptr e.g.
> 
> jdk/src/hotspot/share/compiler/compilationMemoryStatistic.cpp
> 
> Line 79 in [b3bcc49](https://github.com/openjdk/jdk/commit/b3bcc49491b8f8ad337eb4c06201a5468e5c1159)
> 
> ```
>  const CompileTask* const task = th->task(); 
> ```

Yes, it is inconsistent. Allmost all code here (notably anything triggered from start- or end-compilation) are called from the compiler so we run on a compiler thread and in the scope of a ciEnv. So most of the existing nullptr checks are probably not needed. 

We may want to make this consistent with subsequent RFEs.

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

PR Comment: https://git.openjdk.org/jdk/pull/18864#issuecomment-2082141621