RFR: 8343767: Enumerate StubGen blobs, stubs and entries and generate code from declarations

[Andrew Dinn]

On Thu, 14 Nov 2024 19:26:54 GMT, Vladimir Ivanov <vlivanov at openjdk.org> wrote:

>> When we come to add save and restore we will need to have the id to do the AOT cache lookup then generate the stub if not found on a production run as well as to write the stub if this is an assembly run. So, I'll leave this a is for then.
>> 
>> Also, at some point I want to add an assert that the stub generator should be 'expecting' this stub which means I will need to pass it this id. A stub generator knows which blob it is writing into (it gets passed the blob id when constructed) and the template macros generate a debug-only method to translate a stub id to the blob (id) named in the stub declaration. So, we can use that to cross-check that the declared blob matches the one the stub gets written to. Quite a few (generic) stubs were being written to different blobs by different arches so it will be good to ensure they end up in the same blob.
>> 
>> That's not 100% the full picture just now because we also have StubGenerator instances responsible for writing the icache flush stub and (on x86 only) vm_version stubs and they have no associated blob id. I'd like to fold those stubs and their associated blobs into the declaration structure too at some point. For now I'll make sure they are associated with blob_id == NO_BLOBID.
>
> Ok, it makes sense. As an idea, `StubCodeMark` can be used to hide some of that logic. (As an example, different marks on MacroAssembler mess with its instances to customize their behavior.)

n.b. the latest version has `StubCodeMark` assert that stub id matches the blob id.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21957#discussion_r1850635610