RFR: 8338566: Missing membar in ciEnv::get_or_create_exception before publishing handle

[Dean Long]

On Thu, 12 Sep 2024 07:39:02 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

>> Similar to [JDK-8251923](https://bugs.openjdk.org/browse/JDK-8251923), we need a store-store barrier before publishing a handle because otherwise another thread could observe the handle before it's fully initialized and read null from it. This affects architectures with a weak memory model like AArch64.
>> 
>> Unfortunately, this only happened twice in our testing and I was never able to reproduce it.
>> 
>> Thanks,
>> Tobias
>
> Thanks for looking into this, David and Dean. Good points, I agree that we would need to make this completely thread-safe to prevent a leak. Looking at the code again, I wonder why we even do all this lazily, especially since we already create `NullPointerException` and `ArithmeticException` eagerly at VM startup:
> https://github.com/openjdk/jdk/blob/438121be6bdb085fa13ad14ec53b09ecdbd4757d/src/hotspot/share/memory/universe.cpp#L1086-L1089
> 
> Couldn't we do the same for `ArrayIndexOutOfBoundsException`, `ArrayStoreException` and `ClassCastException`? This would save us quite some complexity and I think the startup / footprint overhead is negligible.

@TobiHartmann Yes, that seems like the best idea.  I was going to suggest moving the fields into the CompilerThread, which gets rid of the race and limits the redundant objects, but I like your idea better.

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

PR Comment: https://git.openjdk.org/jdk/pull/20950#issuecomment-2345788504