RFR: 8309688: Data race on java.io.ClassCache$CacheRef.strongReferent [v3]

Aleksey Shipilev shade at openjdk.org
Wed Jun 14 09:54:03 UTC 2023


On Tue, 13 Jun 2023 20:42:49 GMT, Man Cao <manc at openjdk.org> wrote:

>> Hi all,
>> 
>> Could anyone review this small fix for a data race in java.io.ClassCache$CacheRef? This fix makes the code safer by making the code data-race-free.
>
> Man Cao has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Switch to using volatile instead of AtomicReference

Unfortunately, even the single `volatile` on that fast path seems to cost quite a bit :(

On M1:


# CONF=macosx-aarch64-server-release make images test TEST=micro:java.io.ObjectStreamClasses

Benchmark                       Mode  Cnt    Score   Error  Units

# Before
ObjectStreamClasses.testLookup  avgt    8  106,946 ± 0,691  ns/op

# After
ObjectStreamClasses.testLookup  avgt    8  119,984 ± 0,588  ns/op


So again, this looks like a benign data race, and we are penalizing the serialization a bit even with the lightweight fix. This is only to make TSAN happy, right? If so, I would rather keep the code as is.

There are plenty of benign data races in JDK, we should be able to somehow tell TSAN which are actually fine.

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

PR Comment: https://git.openjdk.org/jdk/pull/14386#issuecomment-1590869101


More information about the core-libs-dev mailing list