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

[White, Derek]

Hi Martin,

That's a good point, and one that Thomas has been trying to make to me think about: Do all allocation paths need to worry about this?

If the fast-path allocations done by the interpreter and jitted code only occur in young gen regions, and the concurrent collectors never look at the young gen concurrently, then CPU -specific code probably wouldn't have to worry about it. The fixed code in the runtime slow paths would handle all of the problem allocations.

Note that we have a tower of undocumented and untested assumptions about some pretty subtle stuff, that exists in code only as the absence memory ordering instructions. :-)

So it seems that CMS violates those constraints by sometimes doing TLAB-like allocations out of the old gen (when concurrent sweep in progress?).

I think 

-----Original Message-----
From: Doerr, Martin [mailto:martin.doerr at sap.com] 
Sent: Tuesday, December 20, 2016 9:28 AM
To: Doerr, Martin <martin.doerr at sap.com>; Andrew Haley <aph at redhat.com>; 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

I noticed that the tag field is read by ldarb, so forget my comment below.

I can't see how the memory which is getting initialized can get accessed by another thread before the membar(Assembler::StoreStore) at the end was executed. Another thread would need the oop pointing to the memory.

And TLAB scanning can only be done at a safepoint as far as I know.

Best regards,
Martin


-----Original Message-----
From: hotspot-runtime-dev [mailto:hotspot-runtime-dev-bounces at openjdk.java.net] On Behalf Of Doerr, Martin
Sent: Dienstag, 20. Dezember 2016 12:14
To: Andrew Haley <aph at redhat.com>; 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

Hi,

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

Best regards,
Martin


-----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?

Andrew.