RFR: 8365400: Enhance JFR to emit file and module metadata for class loading

Markus Grönlund mgronlun at openjdk.org
Wed Nov 26 13:49:50 UTC 2025


On Wed, 26 Nov 2025 13:01:30 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> Greetings,
>> 
>> this enhancement adds a "source" field, label "Location" to the jdk.ClassDefine event.
>> 
>> To enable this functionality, JFR needs a concurrent symbol table. We can build a simpler version of a concurrent hash table, taking advantage of the JFR epoch system. This will be useful also for planned future enhancements.
>> 
>> Extensions are made to AOT to consistently report identical canonical paths for classes as non-AOT code paths.
>> 
>> Testing: jdk_jfr, manual AOT verification, stress testing
>> 
>> Thanks
>> Markus
>
> src/hotspot/share/jfr/support/jfrSymbolTable.hpp line 68:
> 
>> 66: 
>> 67:   void on_link(const Symbols::Entry* entry);
>> 68:   void on_unlink(const Symbols::Entry* entry);
> 
> What is Symbols ? Is it a JFR thing, so should it be JfrSymbols ?

It's a more effective version of a concurrent hash table because we employ invariants that apply only to JFR (no concurrency state (hazard ptrs, global counters etc) is needed to track concurrency; only CAS insertions are made into the mapped primary bucket, searches are stable searches in the epoch-current list).

Symbols are mainly the regular runtime Symbols, but we also have an extension for tracking const char*s c-strings.

A JFR symbol is a constant pool construct, mapped onto an epoch-relative id.

Since the Symbols here are typedeffed inside a JFR class, its scope is already a JFR specific construct.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28505#discussion_r2565077778


More information about the hotspot-jfr-dev mailing list