RFR: 8350893: Use generated names for hand generated opto runtime blobs

[Andrew Dinn]

On Mon, 3 Mar 2025 15:51:42 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> @vnkozlov
>>> It could be something changed in code generation but StubRoutines (finalstubs) is not helpful.
>> 
>> Agreed. Although, I don't think that relates to this change. I am investigating.
>
>> Agreed. Although, I don't think that relates to this change. I am investigating.
> 
> Thank you. To be clear, it is not for these changes. I just thought you may know something since you are touching this code.

@vnkozlov I found the reason for the change in what gets printed and it is a bit ugly. It relates to [JDK-8320272: Make method_entry_barrier address shared](https://bugs.openjdk.org/browse/JDK-8320272) which promoted the method_entry_barrier stub up into shared code. It included this change in the AArch64 barrier set:


  if (slow_path == nullptr) {
-     __ movptr(rscratch1, (uintptr_t) StubRoutines::aarch64::method_entry_barrier());
+     __ lea(rscratch1, RuntimeAddress(StubRoutines::method_entry_barrier()));
    __ blr(rscratch1);
    __ b(skip_barrier);


So, the disassembler now prints details of that address via `nmethod::reloc_string_for(u_char* begin, u_char* end)` which does this


    case relocInfo::runtime_call_type:
    case relocInfo::runtime_call_w_cp_type: {
      stringStream st;
      st.print("runtime_call");
      CallRelocation* r = (CallRelocation*)iter.reloc();
      address dest = r->destination();
      CodeBlob* cb = CodeCache::find_blob(dest);
      if (cb != nullptr) {
        st.print(" %s", cb->name());
      } else {
        ResourceMark rm;
        const int buflen = 1024;
        char* buf = NEW_RESOURCE_ARRAY(char, buflen);
        . . .


i.e. it appends the blob name "StubRoutines (final_stubs)". My cleanup did not change that behaviour.

I'm not sure which jdk23 release you are using and how it gets the result you mentioned above. I built jdk-23-ga and it also appended the blob name when I printed an nmethod. I also tried the latest jdk21 (Red_Hat-21.0.6.0.7-1). It did not print the runtime_call annotation, instead just showing the decimal value of the first mov constant


  0x0000ffff5aacbc50:   mov	x8, #0x9980                	// #39296
  0x0000ffff5aacbc54:   movk	x8, #0x5a57, lsl #16
  0x0000ffff5aacbc58:   movk	x8, #0xffff, lsl #32
  0x0000ffff5aacbc5c:   blr	x8


I think the "Stub::stub_name" format printout must occur in some intermediate version of the disassembler prior to the fix I mentioned above where the mov;movk;movk;br sequence is recognized as a call to a known address, as encoded by the three mov insns. There is a routine in the disassembler which adds a post-comment in that format when an address is recognized as belonging to a runtime blob.

I think we probably need to patch the disassembler reloc processing so that it recognises the four multi-stub (i.e. stub code generator) blobs as a special case and rather than just appending the blob name instead identifies which embedded stub code range the target address belongs to and prints that specific stub's name. I'll raise a separate JIRA for that.

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

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