RFR: 8353014: Exclude AOT tooling classes from AOT cache [v2]

[John R Rose]

On Tue, 1 Apr 2025 16:35:38 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> When creating the AOT configuration file or the AOT cache file, we load a few "AOT tooling" classes that are not needed in the production run. This PR adds an API for filtering out such classes to reduce footprint.
>> 
>> In addition, with the upcoming [JDK-8325147](https://bugs.openjdk.org/browse/JDK-8325147) (Ahead-of-Time Method Profiling), profiles for the tooling classes will be also be excluded. This will prevent the JVM from compiling methods at start-up which aren't going to be used.
>
> Ioi Lam has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains four commits:
> 
>  - Refactored CollectClassesForLinking for simplification
>  - Merge branch 'master' into 8353014-exclude-tooling-classes-from-aot-cache
>  - Reverted some fixes in systemDictionaryShared.cpp that causes test failures
>  - 8353014: Exclude AOT tooling classes from AOT cache

Maybe not for this upstream but for the next:  I notice that the access to the static filter variable (in `FilterMark`) assumes single-threaded operation, which is true in the assembly phase.  But there is no assertion that excludes multi-threaded use.  This code will be more maintainable in the long run if there is an explicit assert of some sort that tries to detect if two threads are using the feature at the same time.

Sketch:  In debug builds only create a second static variable (like `FilterMark::_current_mark_user`) that tells which thread is using the static.  Set it in the constructor; manage it LIFO, like the first static variable.  And guard all reads and writes of the filter with asserts that check that the current thread is the right one.  Set the extra debug variable (`FilterMark::_current_mark_user`) under a briefly locked mutex, for more race detection, but don't read it under a mutex.

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

PR Comment: https://git.openjdk.org/jdk/pull/24272#issuecomment-2776404919