On Tue, 13 May 2025 08:52:17 GMT, David Holmes <dhol...@openjdk.org> wrote:
> Some drive-by comments, not a full review as I find this all rather confusing > because I don't understand why we used "cds" in AOT specific code in the > first place. It makes perfect sense to me that AOT specific code logs to > "aot". > > It makes far less sense to me why you ever introduced logging that required > "cds" and "aot" in the first place, so getting rid of that is a good thing. > > For code shared between cds and aot it is less clear to me how to proceed. If > the intent is that CDS will be no more and everything is AOT, then a > transition path is needed for the logging. I guess this is where your macros > come in, though I'm a bit unclear as to why it can be controlled by a > user-defined command-line flag rather than only by the CDS/AOT selection > arguments operating directly on an internal CDS/AOT configuration setting. ??? Since [JEP 483](https://openjdk.org/jeps/483), all ahead-of-time optimizations in HotSpot fall under the "AOT" umbrella. We have several JEPs for new optimizations that use the AOT terminology. E.g., [JEP 515 - Ahead-of-Time Method Profiling](https://openjdk.org/jeps/515). The traditional CDS functionality is part of (a strict subset of) AOT -- ahead-of-time processing of class metadata. Classical CDS VM flags such as `-Xshare` can be seen as special interfaces to a subset of the AOT functionality. We are providing these flags for backwards compatibility, as there are equivalent ways to access the same features (and more) with the new `-XX:AOTXXX` flags introduced in JEP 483. Eventually, I think we will deprecate and remove the classical CDS flags. Given this background, moving `-Xlog:cds` to `-Xlog:aot` is part of the transition plan. These logs will probably be the first legacy CDS interfaces to be removed from the JDK. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25136#issuecomment-2878368790
