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

[Andrew Dinn]

On Tue, 3 Dec 2024 02:45:09 GMT, Vladimir Ivanov <vlivanov at openjdk.org> wrote:

>> Andrew Dinn has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision:
>> 
>>   increase compiler stub space for macos x86_64
>
> Looks good. 
> 
> Testing results (hs-tier1 - hs-tier4) are clean.

@iwanowww @TheRealMDoerr @offamitkumar

I believe I have now addressed all outstanding issues on all arches:

 - I bumped up the blob sizes to account for merged changes and to allow enough headroom for the compiler stubs on macos/x64
 - I fixed the ppc test failure (my patch to the `TEST_FILL` macro ended up checking whether the accessor was null rather than the accessed field; the same error is now removed on s390)
 - I removed the unused `ppc zero_words_aligned8` stub
 - I fixed an couple of cut and paste errors that messed up the s390 conjoint `obj_uninit` array copy routines. s390 is now passing tier1 tests (albeit grindingly slowly on my borrowed s390 box :-)
 - I updated all copyrights to 2024 for additions/changes made last years and 2025 for changes added since new year

and finally

 - I removed the `repeat_stub` template that was used to declare and generate an array of `lookup_secondary_supers_table` stubs and replaced it with a `do_entry_array` template that is used to declare and generate an array of entries for the now single `lookup_secondary_supers_table` stub.

I believe that last change makes the declarations more coherent. We should not really be declaring/generating a fixed size collection of closely related routines as independent stubs since those routines ought either to be all present or none of them present. Instead it makes much more sense to declare/generate the routines as a single named stub which exposes an array of entries.

This change also simplifies the generation of the associated stub names/enum tags and blob/stub verifier routines. Every stub now has a compile-time constant C string name generated in the names array, a single global enum tag and a single blob-local enum tag.

Also this enables a nice follow-up. We don't currently have unique global or blob/stub-local enum tags for each separate entry (or a base tag plus dedicated range in the case where we declare an array of entries) but it will now be possible to achieve that, allowing us to add further verification including, in Leyden, checking that stored and retrieved entry counts match a stub's associated enum tag range.

@TheRealMDoerr thanks for the already re-reviewing.

@iwanowww @offamitkumar @RealFYang could you please give this one final look over?

@iwanowww would it be appropriate to rerun full tier1-4 tests?

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

PR Comment: https://git.openjdk.org/jdk/pull/21957#issuecomment-2592943666