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

Alan Bateman alanb at openjdk.org
Fri Oct 10 06:51:03 UTC 2025


On Thu, 9 Oct 2025 21:04:41 GMT, Larry Cable <duke at openjdk.org> wrote:

> the existing` jdk.classDefine` and `jdk.ClassLoad` events do not include metadata regarding the location/source of the ClassFile.
> 
> The location of the class file for a class defined can be of utility in both debugging and auditing.
> 
> this addition introduces a new `jdk.ClassFileDefine` event which records the class defined and the location (path/url) of the class file that contained the implementation thereof

The evolution of JFR events isn't clear to me so I don't know if adding a field is compatible or not for programs that are processing recordings. (I'm just trying to understand why a new not-enabled-by-default event is added instead of adding a field to the existing ClassDefine event.

The existing event is emitted in SystemDictionary::define_instance_class, the new event emits it from JVM_DefineClassXXX. Is this because it was awkward to get at cfs->source from the SD code?

I assume that a test will be added as it would be easy to refactor code and not record the event if enabled.

Using "jvm" as the URI scheme when there is no source is a bit strange. There will be custom class loaders that don't provide a code source, do you really want these to use this source in the event?

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

PR Comment: https://git.openjdk.org/jdk/pull/27738#issuecomment-3388530284


More information about the hotspot-dev mailing list