RFR (M): 8029396: PPC64 (part 212): Several memory ordering fixes in C-code.

Vitaly Davidovich vitalyd at gmail.com
Tue Dec 3 13:34:05 PST 2013


Goetz,

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?

Thanks

Sent from my phone
On Dec 3, 2013 2:21 PM, "Lindenmaier, Goetz" <goetz.lindenmaier at sap.com>
wrote:

> 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!
>   Goetz.
>
> 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
> also
> >> 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...
URL: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20131203/30791e40/attachment.html 


More information about the hotspot-runtime-dev mailing list