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

[White, Derek]

Thanks you all for the great discussion. This bug has been closed.

A new bug has been opened to handle the issue of better documentation and assertions: https://bugs.openjdk.java.net/browse/JDK-8172157 "Tighten up contract between concurrent GCs and runtime regarding object allocation and header initialization".

 - Derek

-----Original Message-----
From: White, Derek 
Sent: Wednesday, December 28, 2016 6:11 PM
To: Kim Barrett <kim.barrett at oracle.com>
Cc: Andrew Haley <aph at redhat.com>; Thomas Schatzl <thomas.schatzl at oracle.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 Kim,

Sounds right. I'm working on some comments and assertions to make some of this more clear. I'll get this out  for review Friday or sooner.

- Derek

> On Dec 28, 2016, at 5:59 PM, Kim Barrett <kim.barrett at oracle.com> wrote:
> 
> I think where we've ended up with this discussion is that
> 
> (1) Derek's proposed change should be withdrawn.
> 
> (2) JDK-8171449 should be closed as not an issue.
> 
> (3) There is a FIXME comment in the aarch64 store_klass definition 
> suggesting a release_store might be needed.  That comment appears to 
> be incorrect.
> 
> (4) There are comments on various uses of store_klass in TLAB contexts 
> (for multiple platforms) saying the store_klass must be last due to 
> ordering constraints when using concurrent GCs.  Those comments appear 
> to be doubly incorrect; existing concurrent GCs don't impose such an 
> ordering constraint in TLAB contexts, and there are no membars (on 
> platforms where they are needed) to ensure the suggested ordering.
> 
> (5) There might be uses of store_klass that aren't in TLAB contexts.
> Someone should look for these to determine whether there actually are 
> any, and whether they have any ordering constraints.  If any do have 
> real ordering constraints, then some code changes are likely needed to 
> actually provide that ordering (perhaps an additional ordered form of 
> store_klass).
> 
> (6) It would be *really* nice to have the contracts in this area 
> written down in some more explicit and accessible form than the code 
> and scattered through multiple email threads.
> 
> Does that look like a correct summary?
>