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