In the follow up to JDK-8154750 Zhengyu Gu wrote:
>
> In classLoader.hpp
>
> // Next entry in class path
> ClassPathEntry* next() const { return _next; }
> void set_next(ClassPathEntry* next) {
> // may have unlocked readers, so write atomically.
> OrderAccess::release_store_ptr(&_next, next);
> }
>
> If there are unlocked readers, looks like that load_acquire is needed in
> next() function.
In general we need to verify store_release is always paired with load_acquire on lock-free paths.
>
> In classLoader.hpp
>
> // Next entry in class path
> ClassPathEntry* next() const { return _next; }
> void set_next(ClassPathEntry* next) {
> // may have unlocked readers, so write atomically.
> OrderAccess::release_store_ptr(&_next, next);
> }
>
> If there are unlocked readers, looks like that load_acquire is needed in
> next() function.
In general we need to verify store_release is always paired with load_acquire on lock-free paths.
- relates to
-
JDK-8162826 Missing load-acquire in relation to methodData code
-
- Open
-
-
JDK-8164207 Checking missing load-acquire in relation to _pd_set in dictionary.cpp
-
- Resolved
-
-
JDK-8163437 Initialization logic error in PerfMemory
-
- Closed
-
-
JDK-8163440 Missing load-acquire in relation to CardTableModRefBS::inline_write_ref_field
-
- Closed
-