On Thu, 15 Oct 2026 15:09:02 GMT, Erik Gahlin <[email protected]> wrote:
>> Alright, I've made JfrCPUTimeSampleRequests variable-size. No extra space is >> used when native frames are not recorded. >> Also, replaced per-event setting with a global FlightRecordedOption as >> suggested. > > I wonder about the metadata and the use of the separate nativeFunction > struct. > > The Method type and RecordedMethod class were designed to allow native > methods to be added in the future. > > How about this: > > > <Type name="Method" label="Method"> > <Field type="Class" name="type" label="Type" /> > <Field type="Symbol" name="name" label="Name" /> > <Field type="int" name="modifiers" label="Access Modifiers" /> > <Field type="boolean" name="hidden" label="Hidden" /> > <Field type="Library" name="library" label="Native Library" /> > <Field type="ulong" name="offset" label="Native Offset" /> > </Type> > > > > <Type name="StackFrame"> > <Field type="Method" name="method" label="Java Method" /> > <Field type="int" name="lineNumber" label="Line Number" /> > <Field type="boolean" name="javaFrame" label="Java Frame" /> > <Field type="FrameType" name="type" label="Frame Type" /> > </Type> > > > The javaFrame field is false for non-Java frames, which works when opening a > new recording with an older parser. The Method type reuses the name field, > Java Method is labeled Method and fields for offset and library are added. Yeah, that's what I tried first, before I realized that pretty much all writers and readers assume that `Method` has non-null Java Class. Changing that is possible, but it's going to be a large refactoring in HotSpot regarding how method IDs are managed, and other readers will break on new recordings anyway. Also, there will be a confusing asymmetry in what `Method` means for Java methods vs. non-Java code. I can try to sketch out a version though. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/32524#discussion_r4295200887
