RFR: 7143664: Clean up OrderAccess implementations and usage

[Erik Österlund]

Hi Severin,

Thanks for reviewing the zero changes! :)

/Erik

On 20/02/15 14:19, Severin Gehwolf wrote:
> 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
>
>
>
>