RFR (M): 8029396: PPC64 (part 212): Several memory ordering fixes in C-code.
vitalyd at gmail.com
Tue Dec 3 13:34:05 PST 2013
There's a place where you use release store but the code is already inside
a mutex. Is the mutex impl not guaranteeing release upon exit?
Sent from my phone
On Dec 3, 2013 2:21 PM, "Lindenmaier, Goetz" <goetz.lindenmaier at sap.com>
> Hi Coleen,
> the change is a collection of fixes different people
> in my team did in the past. Many were done after we
> saw errors in tests or at customers. Others, as you describe,
> were found reading the code.
> If you have interest in a particular one, I can try to dig
> out the background.
> Thanks for your review!
> Ps: Now I'm on the gc and rt list.
> -----Original Message-----
> From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com]
> Sent: Tuesday, December 03, 2013 7:47 PM
> To: Lindenmaier, Goetz; hotspot-runtime-dev at openjdk.java.net
> Subject: Re: RFR (M): 8029396: PPC64 (part 212): Several memory ordering
> fixes in C-code.
> He may be not on runtime list.
> On 12/3/13 10:15 AM, Coleen Phillimore wrote:
> > Hi Goetz,
> > I did look at this yesterday. It looks fine. I was trying to find if
> > there were others that might have been missed. How did you find this
> > set in this changeset? Did you look for volatile and find instances
> > that didn't use CAS or other memory ordering instructions? We've done
> > this exercise before but it's easy to miss things.
> > thanks,
> > Coleen
> > On 12/03/2013 12:09 PM, Lindenmaier, Goetz wrote:
> >> Hi,
> >> could somebody of rt and gc please have a look at the following change?
> >> It contains memory ordering fixes as required by the PPC64 port, see
> >> below.
> >> http://cr.openjdk.java.net/~goetz/webrevs/8029396-0-memo/
> >> Thanks and best regards,
> >> Goetz.
> >> -----Original Message-----
> >> From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com]
> >> Sent: Montag, 2. Dezember 2013 22:42
> >> To: Lindenmaier, Goetz; 'hotspot-dev at openjdk.java.net';
> >> 'ppc-aix-port-dev at openjdk.java.net'
> >> Subject: Re: RFR (M): 8029396: PPC64 (part 212): Several memory
> >> ordering fixes in C-code.
> >> These changes need to be reviewed by GC and Runtime group. Especially
> >> first 2 changes (CMS).
> >> The rest 6 changes are less performance critical and, I think they are
> >> fine.
> >> Thanks,
> >> Vlaidmir
> >> On 12/2/13 8:51 AM, Lindenmaier, Goetz wrote:
> >>> Hi,
> >>> This change contains a row of fixes to the memory ordering in
> >>> runtime, GC etc.
> >>> http://cr.openjdk.java.net/~goetz/webrevs/8029396-0-memo/
> >>> These are:
> >>> - Accessing arrays in CMS (compactibleFreeListSpace.cpp)
> >>> - CMS: Do release when marking a card dirty. The release must only be
> >>> done if GC is running. (several files)
> >>> - Method counter initialization (method.hpp).
> >>> - Order accessing f1/f2 in constant pool cache.
> >>> - Release stores in OopMapCache constructor (instanceKLass.cpp).
> >>> - BiasedLocking: Release setting object header to displaced mark.
> >>> - Release state of nmethod sweeper (sweeper.cpp).
> >>> - Do barriers when writing the thread state (thread.hpp).
> >>> Please review and test this change.
> >>> If requested, I can part this into smaller changes. But for now
> >>> I wanted to put them all into one change as they all address the
> >>> problems with the PPC memory model.
> >>> Best regards,
> >>> Goetz.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the hotspot-runtime-dev