RFR: 7143664: Clean up OrderAccess implementations and usage

Severin Gehwolf sgehwolf at redhat.com
Fri Feb 20 13:19:30 UTC 2015


Hi,

On Fri, 2015-02-20 at 12:23 +0000, Erik Österlund wrote:
> Hi all,
> 
> This is a continuation of my original RFR in the hotspot-dev mailing 
> list. Most of it has been reviewed at this point, but there are some 
> zero-specific changes I would appreciate if I could get reviews for.
> 
> I have refactored OrderAccess and fixed some bugs in model and 
> implementation, more information about it can be found in the bug ID:
> https://bugs.openjdk.java.net/browse/JDK-7143664
> 
> The basic idea of the refactoring is to not invent the wheel more than 
> necessary and move a lot of the common patterns from platform specific 
> files to shared code. As a result there is very little code left for the 
> zero-specific files (which hopefully makes the reviewing easier).
> 
> The latest webrev is:
> http://cr.openjdk.java.net/~dholmes/7143664/webrev.v4/
> 
> The webrev increments have all been polishing various comments and 
> copyrights, so no need to read the full conversation of the review 
> thread in hotspot-dev. The first email + bug ID should be enough 
> information.
> 
> The only thing I really changed relevant to zero (apart from removing 
> all the generic code) is:
> 
> 1) To change some terminology - light and full fences instead of READ, 
> WRITE fences in the macros because they do the same thing and I don't 
> think READ and WRITE conceptually says much about what is happening.

That makes sense to me.

> 2) Similarly, I define all barriers directly in terms of the actual 
> barrier sort used, rather than defining e.g. loadstore in terms of 
> acquire and then transitively an actual barrier. Previous approach is 
> awkward because the model mismatches and loadstore might as well belong 
> to release as loadstore is basically the intersection of acquire and 
> release. So basically the abstraction is IMO not useful, just confusing.

Agreed.

> 3) Use consistently same fencing for PPC as the other PPC linux/aix, 
> i.e. lwsync instead of isync for what was previously called the 
> READ_MEM_BARRIER.

OK.

> I kindly ask if anyone could possibly look through these changes please, 
> and see if it is all good?

src/os_cpu/linux_zero/vm/orderAccess_linux_zero.inline.hpp
src/os_cpu/bsd_zero/vm/orderAccess_bsd_zero.inline.hpp

Both look good to me.

Cheers,
Severin

> Thanks,
> /Erik





More information about the zero-dev mailing list