RFR (M): 8029396: PPC64 (part 212): Several memory ordering fixes in C-code.
goetz.lindenmaier at sap.com
Wed Dec 4 03:51:08 PST 2013
I assume you are talking about instanceKlass.cpp?
The release_store forces ordering with what happens in the call to OopMapCache.
This is both within the OopMapCacheAlloc_lock, so the barriers there can not
have an effect on this issue.
From: Vitaly Davidovich [mailto:vitalyd at gmail.com]
Sent: Dienstag, 3. Dezember 2013 22:34
To: Lindenmaier, Goetz
Cc: Vladimir Kozlov; hotspot-runtime-dev at openjdk.java.net
Subject: RE: RFR (M): 8029396: PPC64 (part 212): Several memory ordering fixes in C-code.
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<mailto:goetz.lindenmaier at sap.com>> wrote:
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.
From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com<mailto:vladimir.kozlov at oracle.com>]
Sent: Tuesday, December 03, 2013 7:47 PM
To: Lindenmaier, Goetz; hotspot-runtime-dev at openjdk.java.net<mailto: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.
> On 12/03/2013 12:09 PM, Lindenmaier, Goetz wrote:
>> 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
>> Thanks and best regards,
>> -----Original Message-----
>> From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com<mailto:vladimir.kozlov at oracle.com>]
>> Sent: Montag, 2. Dezember 2013 22:42
>> To: Lindenmaier, Goetz; 'hotspot-dev at openjdk.java.net<mailto:hotspot-dev at openjdk.java.net>';
>> 'ppc-aix-port-dev at openjdk.java.net<mailto: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
>> On 12/2/13 8:51 AM, Lindenmaier, Goetz wrote:
>>> This change contains a row of fixes to the memory ordering in
>>> runtime, GC etc.
>>> 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,
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the hotspot-runtime-dev