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