RFR(s): 8171449" [aarch64] store_klass needs to use store release
Derek.White at cavium.com
Wed Dec 28 23:10:40 UTC 2016
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.
> 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
> (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?
More information about the hotspot-runtime-dev