RFR: 8282420: JFR: Remove event handlers [v6]

[Doug Simon]

On Tue, 10 May 2022 14:42:58 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

>> Hi,
>> 
>> Could I have a review of a fix that removes event handler classes for JFR. Bytecode for event instrumentation is now only added to the event class. Benefits are:
>> 
>> - No class memory leak in the boot class loader.
>> - Reduce overhead from class loading during startup, which is important with additional JDK events that are coming (VirtualThreadStart etc.)
>> - One less frame to traverse when recording a Java stack trace.
>> 
>> Future benefits are:
>> 
>> - Simplify creating instrumentation as a build step. See https://bugs.openjdk.java.net/browse/JDK-8279354
>> - Simplify implementation of Event Metrics. See https://bugs.openjdk.java.net/browse/JDK-8224749
>> 
>> When the Security Manager is removed, much of the code being added for security reasons can be deleted.
>> 
>> There are few JFR hooks when code is being linked. Plan is to also use these for other events later. 
>> 
>> Testing: tier 1-4, jdk/jdk/jfr
>> 
>> Thanks
>> Erik
>
> Erik Gahlin has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Minor fixes

src/hotspot/share/jfr/instrumentation/jfrResolution.hpp line 40:

> 38:  public:
> 39:   static void on_runtime_resolution(const CallInfo & info, TRAPS);
> 40:   static void on_c1_resolution(const GraphBuilder * builder, const ciKlass * holder, const ciMethod * target);

Should the declarations of `on_c1_resolution` and `on_c2_resolution` be guarded with `COMPILER2_PRESENT` and `COMPILER1_PRESENT` since the method bodies are?

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

PR: https://git.openjdk.org/jdk/pull/8383