RFR(XXS): 8165018: Missing memory barrier for PPC64 in Unsafe_GetObjectVolatile
martin.doerr at sap.com
Fri Sep 2 14:40:23 UTC 2016
first of all, thanks, David, for the review and for sponsoring.
I'm not sure if it's a bug that Unsafe_GetObjectVolatile does not perform the G1 barrier.
One could argue that users of Unsafe should know what they are doing and reading the referent field by Unsafe_GetObjectVolatile may be unsupported.
On the other hand, if somebody tries to do this, G1 may unexpectedly remove the java object to which the reference was returned by Unsafe_GetObjectVolatile.
No clue if there's anybody out there who will ever run into such a bad situation.
Thanks and best regards,
From: David Holmes [mailto:david.holmes at oracle.com]
Sent: Freitag, 2. September 2016 07:04
To: Doerr, Martin <martin.doerr at sap.com>; hotspot-runtime-dev at openjdk.java.net; hotspot-gc-dev at openjdk.java.net
Subject: Re: RFR(XXS): 8165018: Missing memory barrier for PPC64 in Unsafe_GetObjectVolatile
Adding GC folk
On 30/08/2016 8:51 PM, Doerr, Martin wrote:
> we found that a memory barrier for PPC64 is missing in the current Unsafe implementation. get_volatile already contains the memory barrier for "support_IRIW_for_not_multiple_copy_atomic_cpu". The same is needed in Unsafe_GetObjectVolatile.
> Here's my webrev:
That looks fine to me.
> And while looking at it I wonder why Unsafe_GetObjectVolatile does not contain a G1 barrier like Unsafe_GetObject. Is it not possible to use the Volatile version to access the referent field of a Reference?
That looks like a bug to me. :)
> Please review. As it is shared code, I will need a sponsor, please.
I can sponsor.
> Best regards,
More information about the hotspot-gc-dev