On Thu, 24 Oct 2024 03:01:54 GMT, Ioi Lam <ik...@openjdk.org> wrote: >> This is an implementation of [JEP 483: Ahead-of-Time Class Loading & >> Linking](https://openjdk.org/jeps/483). >> >> ---- >> Note: this is a combined PR of the following individual PRs >> - https://github.com/openjdk/jdk/pull/20516 >> - https://github.com/openjdk/jdk/pull/20517 >> - https://github.com/openjdk/jdk/pull/20843 >> - https://github.com/openjdk/jdk/pull/20958 >> - https://github.com/openjdk/jdk/pull/20959 >> - https://github.com/openjdk/jdk/pull/21049 >> - https://github.com/openjdk/jdk/pull/21143 > > Ioi Lam has updated the pull request incrementally with two additional > commits since the last revision: > > - 8342907: Implement AOT testing mode for jtreg tests (authored by @katyapav) > - disable test that fails with hotspot_runtime_non_cds_mode
A thought for a possible cleanup, after this PR is done… The scratch mirror logic had me… scratching my head. It seems to me that a more descriptive name would make the code explain itself better. I suggest (for a future cleanup) calling a mirror structure which is being aot-assembled (just for the archive) a "future mirror" (or maybe "production mirror" or "mirror asset"). This is in distinction to the current "live" mirror, which is also the AOT phase mirror. In general, from the point of view of the assembly phase, when we build new structures not created by the JVM as a result of post-training Java execution, we might want to give them a common descriptive term. But I suppose most items that make it into the AOT cache are faithful copies of live data, present in the VM at dump time (end of assembly phase). In that case, it's more like "the same structure" in all cases, and there's no need to simultaneously work on both present and future versions of the same structure. (When I say "structure" I mean mirror object for now, but perhaps the pattern might expand to something else? Or, maybe we will get rid of the two-mirror solution, in which case every future structure is also completely present and live in the assembly-phase VM.) ------------- PR Comment: https://git.openjdk.org/jdk/pull/21642#issuecomment-2434387290
