On Fri, 16 Oct 2026 13:32:32 GMT, Andrei Pangin <[email protected]> wrote:
>> 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. It's tricky to asses, it would help to get a rough idea of what would be needed. Keeping everything in one structure also works best for printing (JSON/XML) and possible API support in the future, e.g. RecordedMethod::getLibrary(). ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/32524#discussion_r4388297799
