On Mon, 29 Jun 2026 13:57:55 GMT, Andrew Dinn <[email protected]> wrote:
>> David Simms has updated the pull request with a new target base due to a >> merge or a rebase. The pull request now contains 2859 commits: >> >> - Merge branch '8317277' into jep401_sub_review_8317278 >> - Merge remote-tracking branch 'valhalla/lworld' into 8317277 >> - Merge >> >> Merge jdk-28+4 >> - 8386963: [lworld] Improve the exception message from Object >> synchronization methods on value objects >> >> Reviewed-by: dholmes, alanb >> - 8387300: [lworld] Minor review comments in javac >> >> Reviewed-by: vromero >> - 8387192: [lworld] Review comment drop for core libs >> >> Reviewed-by: jvernee, vromero >> - 8386999: [lworld] C2: assert(is_dead_loop_safe()) failed: shouldn't be >> cleared yet >> >> Reviewed-by: qamai, vlivanov >> - 8386787: [lworld] >> compiler/valhalla/inlinetypes/TestValueConstruction.java#StressIncrementalInliningDontInlineMyAbstractInit >> timed out >> >> Reviewed-by: phubner, chagedorn >> - 8386995: [lworld] Duplicate value classes are a preview feature warning >> >> Reviewed-by: alanb, vromero >> - 8383389: [lworld] Augment AOTMapLogger::print_oop_details to support flat >> arrays with oops >> >> Reviewed-by: iklam, fparain >> - ... and 2849 more: https://git.openjdk.org/jdk/compare/193de1b1...cffcfb57 > > src/hotspot/cpu/aarch64/stubGenerator_aarch64.cpp line 13771: > >> 13769: >> 13770: if (InlineTypeReturnedAsFields) { >> 13771: StubRoutines::_load_inline_type_fields_in_regs = > > This looks suspicious. > > I noticed that the generator code for this stub is not attempting to look up > the stub in the AOT cache as with other `StubGen initial` stubs. On > investigation I also noticed that the generator is allocating its own code > buffer to write the code into and then wrapping it up in its own > `RuntimeStub` before handing back the entry address. > > I'm not really sure why this stub has been bundled in with the other `StubGen > initial` stubs. `StubGen` stubs are generated in related groups with all > stubs in the group sharing a common code blob. So all the `initial` stubs are > expected to be in the `StubGen initial` blob. > > If this stub needs to be in it's own standalone blob then perhaps it needs to > be declared as a `Shared` stub in its own blob rather than being lumped in > with the `StubGen initial` stubs? Was there a good reason to try generating > it here amongst the `initial` blobs? e.g. timing of generation? Looking further into this I cannot see anywhere where these stubs are being used? So, it's hard to say what is really needed here. However, it looks to me as if these two return value stubs ought to be generated as `SharedRuntime` stubs. That is where we generate stubs that need their own blob and also require an associated oop map. The right time to generate looks like under the call to `SharedRuntime::generate_initial_stubs()`. That will occur just after generation of the `StubGen initial` stubs i.e. before generating any of the gc/jfr/continuation stubs or interpreter and before calling `AOTCodeCache::init3()`. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/31122#discussion_r3499001429
