RFR: 8338379: Accesses to class init state should be properly synchronized [v2]

[Aleksey Shipilev]

On Mon, 23 Sep 2024 09:23:29 GMT, David Holmes <dholmes at openjdk.org> wrote:

> The problem is we have completely different code paths that look at the different states of a class (loaded, linked, initialized, in-error) and those actions use different locks. This issue was, I thought, only about the lock-free fast-paths checking the "is initialized" state not anything else. These extra barriers could be completely redundant for "is loaded" or "is linked" or "is in error" checks.

Right. I chose this code shape to make sure we cover _all_ paths that poll `init_state` to extra safety. We could, in principle, only protect `is_initialized()` path with the acquire. But I think we then start to depend on downstream code not doing "smart" things bypassing that check, for example polling `is_loaded() { _init_state >= loaded }` to implicitly (and too optimistically) check for `init_state >= fully_initialized`, or even doing `init_state() > being_initialized` somewhere. 

I would not discount the possibility that something somewhere would depend on pre-fully-initialized states to publish the intermediate class state. Looking around, I see some interesting uses in `InstanceKlass::methods_do`, `ClassLoaderData::methods_do`, `ClassLoaderData::loaded_classes_do`, `LoaderConstraintTable::find_constrained_klass`, ...

It feels much safer to be extra paranoid here.

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

PR Comment: https://git.openjdk.org/jdk/pull/21110#issuecomment-2368197595