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

[Ioi Lam]

On Thu, 3 Apr 2025 21:59:46 GMT, Ioi Lam <iklam at openjdk.org> wrote:

> > 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.
> 
> I changed the assert to use `Atomic::cmpxchg`. Do you think this will be thread safe?
> 
> > 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.
> 
> One complication is that the filter is actually used at the end of a training run (where we regenerate the MH holder classes), so there could potentially be lingering application threads that load classes currently. With this PR, all of such classes will be classified as "tooling" and will be excluded from the training run's output (the AOT configuration file), which is just fine.
> 
> This is the reason I cannot assert against the current thread that consults the filter.

I realized that my older version of `AOTClassFilter::is_aot_tooling_class()` could have a race condition when reading `_current_mark`. I uploaded a version that prevents this with the `DumpTimeTable_lock`, which is already held when this function is called. I also use the same lock for the constructor/destructor.

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

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