RFR (M): 8029396: PPC64 (part 212): Several memory ordering fixes in C-code.
David Holmes
david.holmes at oracle.com
Thu Dec 19 02:52:03 PST 2013
Somewhat late but I was away for two weeks.
GC stuff:
Is the use of the new release parameter always set to true from shared
code? If so I don't have a problem with it being used to optimize the
stores under certain conditions. But if pcc64 will pass true where other
archs won't then again I object to this because it should be an
algorithmic correctness requirement that is always present.
General: I find a lot of the commentary excessively platform specific.
Eg We don't expect any C++ compiler we currently use to emit memory
barriers for C++ volatiles. If they start doing that we will have a
bazillion unnecessary injected barriers in our code!
BiasedLocking:
It is not clear to me that the BiasedLocking change is needed. AFAICS
there is only one path where revoke_bias is not called at a safepoint
and the comments around that seem to indicate that it was considered
safe to do so. It may be they assumed TSO when making that decision but
I'd be interested to know how this change was arrived at.
Thread state:
The thread state changes have me most concerned as they are heavily used
and so the performance impact here could be extensive. Many of them
occur on paths that involve membars or membar-equivalent actions so they
would seem redundant then. Again I would like to see some analysis
showing these are in fact essential for correctness. There may well be
some situations where they are, but to me this seems an even better
candidate for adding the "release" parameter when needed!
David
-----
On 3/12/2013 2: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.
>
More information about the ppc-aix-port-dev
mailing list