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