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