RFR: 8350893: Use generated names for hand generated opto runtime blobs [v2]

[Andrew Dinn]

On Tue, 4 Mar 2025 18:07:13 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> @shipilev
>>> I am confused that we have OptoRuntime::stub_id(...), and then we also have newly added by you . . .
>> 
>> I'm not sure what you mean here. I think you are referring to `OptoRuntime::stub_name(address entry)` and contrasting it with `OptoRuntime::stub_name(OptoStubId id)`? Is that right? If so ...
>> 
>> The first method is currently used in a couple of places in the C2 compiler to label calls that 1) employ a constant target address and 2) are expected to target one of the opto runtime stub (which also means a specific opto runtime blob since runtime blobs and stubs are 1-1). The stub id associated with the call is probably known -- or, if not, could certainly be coded explicitly -- some way up the call chain, sometimes in a direct caller, sometimes indirectly via a common helper (like the maths helpers). No matter high up the chain you have to go something is looking up that address using an explicit named accessor associated with an explicit stub id.
>> 
>> However, as things are currently coded the direct calls to that first method only know the call target address. The stub id is not available at the point of call and propagating a stub id or stub name down would require some refactoring. Indeed, the current mess actually involves propagating down an extra, hard-wired name (char*) that is used alongside the string returned by `stub_name(address)`. So, yes, I agree that all really ought to be sorted out, allowing this method to be retired -- but not in this PR.
>> 
>> Meanwhile, the second method is used for a very different purpose at points where a stub id definitely is known. It ensures that stub generation is primarily driven off the stub declaration or rather its corresponding id tag. All generator methods now retrieve the name using the id rather than hard-wiring it. This does not just apply for opto runtime stubs. There is an equivalent lookup scheme for shared runtime, c1 runtime and stubgen stubs.
>
> Thank you, @adinn, for investigating relocation info printouts. My bad, I compared output running old Leyden JDK where I added additional code for relocations printouts: https://github.com/vnkozlov/jdk/commit/4d739c91f1ca3409a5aed114c725485fed4dacc4
> 
> May be I should push this into mainline.

@vnkozlov Ah ok, that explains why I was not seeing the same output.
Yes, I agree this ought to go into mainline. I raised issue [JDK-8351256](https://bugs.openjdk.org/browse/JDK-8351256) and PR [23915](https://github.com/openjdk/jdk/pull/23915)

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

PR Comment: https://git.openjdk.org/jdk/pull/23829#issuecomment-2700314351