On Tue, 26 May 2026 22:25:26 GMT, Benjamin Peterson <[email protected]> wrote:
>> Benjamin Peterson has updated the pull request incrementally with one >> additional commit since the last revision: >> >> add comment before continue > > Thank you. Any suggestions for who to tag for a second review? @benjaminp I am happy to review this as is. I'll just make a few observations which any help with documenting the output that appears in the listing. This problem is specific to StubGenerator code blobs which are the only ones that include multiple stubs in a blob. Most of the StubGenerator blobs embed *managed* stubs whose details, including the blob and stub names, are declared in shared file `runtime/stubDeclarations.hpp`. A few (GC blobs) still include *unmanaged* stubs. Details of the latter, inlcuding names, are hard-coded somewhere in the generator code. All StubGenerator stubs have an associated StubCodeDesc created with an associated stub group and stub name. Unmanaged stubs are not guaranteed to define these consistently. However, with managed stubs there is a clear way of identifying these values. The group name is always `"StubRoutines"`. Arguably it ought to be something more useful, indicating that this is a StubGen stub and perhaps also identifying the actual group of StubGen stubs in the blob (initial, compiler etc) but we used `"StubRoutines"` because that was what was used in older releases and we were trying not to break tests or user code that processed diagnostic and log output. The stub name is always uniformly derived from the `do_stub` declaration in `runtime/stubDeclarations.hpp`. So, for example for the preuniverse `fence` stub the relevant declaration line specifies `do_stub(preuniverse, fence)` and the stub name that results is `"fence_stub (stub gen)"`. Again, one might argue that this is not a useful format but i) it is uniform with the format used for non-StubGen blobs/stubs e.g. `"moitorenter_blob (C1 runtime)"` and ii) it only mildly perturbs the formats used in older releases. Note that in the case of the stub you are testing for the declaration employs the previously chosen name `call_stub` so the resulting full name is `"call_stub_stub (stub gen)"`! ------------- PR Comment: https://git.openjdk.org/jdk/pull/31007#issuecomment-4554084255
