From erik.osterlund at lnu.se Fri Feb 20 12:23:30 2015 From: erik.osterlund at lnu.se (=?iso-8859-1?Q?Erik_=D6sterlund?=) Date: Fri, 20 Feb 2015 12:23:30 +0000 Subject: RFR: 7143664: Clean up OrderAccess implementations and usage Message-ID: 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 From sgehwolf at redhat.com Fri Feb 20 13:19:30 2015 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Fri, 20 Feb 2015 14:19:30 +0100 Subject: RFR: 7143664: Clean up OrderAccess implementations and usage In-Reply-To: References: Message-ID: <1424438370.3408.9.camel@redhat.com> 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 From erik.osterlund at lnu.se Fri Feb 20 14:01:09 2015 From: erik.osterlund at lnu.se (=?iso-8859-1?Q?Erik_=D6sterlund?=) Date: Fri, 20 Feb 2015 14:01:09 +0000 Subject: RFR: 7143664: Clean up OrderAccess implementations and usage References: <1424438370.3408.9.camel@redhat.com> Message-ID: 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 > > > >