RFR(s): 8171449" [aarch64] store_klass needs to use store release

Doerr, Martin martin.doerr at sap.com
Tue Dec 20 11:13:45 UTC 2016


I think an acquire barrier is missing. See ppc implementation
"isync(); // Order load of instance Klass wrt. tags."

Best regards,

-----Original Message-----
From: hotspot-runtime-dev [mailto:hotspot-runtime-dev-bounces at openjdk.java.net] On Behalf Of Andrew Haley
Sent: Dienstag, 20. Dezember 2016 11:28
To: Thomas Schatzl <thomas.schatzl at oracle.com>; White, Derek <Derek.White at cavium.com>; aarch64-port-dev at openjdk.java.net; hotspot-runtime-dev at openjdk.java.net
Subject: Re: RFR(s): 8171449" [aarch64] store_klass needs to use store release

On 20/12/16 10:21, Thomas Schatzl wrote:
> Derek can very likely tell you more about the protocol between CMS'
> concurrent threads and the mutators, but both collectors have 
> protocols to ensure that the memory contains valid information, either 
> retrying later (G1), or busy waiting (CMS, afaics from code around a 
> "bugfix for systems with weak memory model" comment) until this is the case.

Yeah.  This stuff doesn't make any sense: I need to see the code.  I guess that what's going on is that a humongous object is allocated, the memory is zeroed, and the memory is then returned to the Java thread, which then initializes the object.  So, the object is reachable from the GC thread even before it has been initialized.  But instances of Class aren't humongous... or are they?


More information about the hotspot-runtime-dev mailing list