On Tue, 29 Sep 2026 22:52:40 GMT, Andrei Pangin <[email protected]> wrote:
>> While fixing this, I found a pre-existing concurrency bug in the CPU-time >> sampler. >> Please take a look at that fix too (which is a prerequisite for this PR). >> https://github.com/openjdk/jdk/pull/32842 > > 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. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/32524#discussion_r4284735367
