RFR(XXS): 8165018: Missing memory barrier for PPC64 in Unsafe_GetObjectVolatile

Doerr, Martin 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,

-----Original Message-----
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

Hi Martin,

Adding GC folk

On 30/08/2016 8:51 PM, Doerr, Martin wrote:
> Hi,
> 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:
> http://cr.openjdk.java.net/~mdoerr/8165018_UnsafePPC64/webrev.00/

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,
> Martin

More information about the hotspot-runtime-dev mailing list