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

[Vladimir Kozlov]

On Tue, 4 Mar 2025 12:17:18 GMT, Andrew Dinn <adinn at openjdk.org> wrote:

>>> > Hm. It looks like in release builds all of these would be "runtime stub"? Is that expected?
>>> We could perhaps fix it to say something more useful. Maybe in a separate PR in case something depends on it having that value in release builds?
>> 
>> I am confused that we have `OptoRuntime::stub_id(...)`, and then we also have newly added by you:
>> 
>> 
>> runtime.hpp:
>> 
>>   // Returns the name associated with a given stub id
>>   static const char* stub_name(OptoStubId id) {
>>     assert(id > OptoStubId::NO_STUBID && id < OptoStubId::NUM_STUBIDS, "stub id out of range");
>>     return _stub_names[(int)id];
>>   }
>> 
>> 
>> Maybe `OptoRuntime::stub_name` should be calling that one directly, instead of going all the way through `CodeCache::find_blob`? Then we don't need any debug-defines there.
>
> @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.

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

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