RFR: 8225716: G1 GC: Undefined behaviour in G1BlockOffsetTablePart::block_at_or_preceding
Aleksey Shipilev
shade at redhat.com
Mon Jun 17 13:05:36 UTC 2019
On 6/17/19 2:53 PM, Andrew Haley wrote:
> On 6/17/19 1:46 PM, Aleksey Shipilev wrote:
>> On 6/17/19 2:37 PM, Andrew Haley wrote:
>> Well, there are OrderAccess j(u)byte methods you can use here, along
>> with some STATIC_ASSERTs that verify uchar and jubyte actually
>> agree? Or even explicit fences before/after the access to get
>> acquire/release?
>
> We want no fences. These are relaxed loads and stores.
Ah. Ah... What does it even mean to have the relaxed load/store of u_char? u_char should be
access-atomic already, since sizeof(u_char) == 1? It does not hurt here, though. Re-reading the
original review thread, it seems to be the cleanliness choice to use explicit Atomic::(load|store),
and the absence of it does not readily hurt.
>> It would be awkward to have the same bug ID having different memory
>> semantics fixes.
>
> I can't see any way to do it otherwise: we have no relaxed atomics on
> 8u that I can find. maybe they're hiding, but I don't think so.
"volatile" is fine then.
--
Thanks,
-Aleksey
More information about the jdk8u-dev
mailing list