RFR: 7143664: Clean up OrderAccess implementations and usage

Erik Österlund erik.osterlund at lnu.se
Fri Feb 20 12:23:30 UTC 2015


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

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

Thanks,
/Erik


More information about the zero-dev mailing list