RFR(M): 8154736: enhancement of cmpxchg and copy_to_survivor for ppc64

Thu Apr 26 12:04:48 UTC 2018

Hi David,

>So the very last comment there was about not implicitly assuming
>memory_order_consume, yet that has not been addressed in the proposal.
>
>Further the discussion on hotspot-runtime-dev through September and
>October was far more illuminating. I think my post here:
>
https://urldefense.proofpoint.com/v2/url?u=http-3A__mail.openjdk.java.net_pipermail_hotspot-2Druntime-2Ddev_2016-2DOctober_021617.html&d=DwICJg&c=jf_iaSHvJObTbx-siA1ZOg&r=oecsIpYF-cifqq2i1JEH0Q&m=G-yYtdHSoT4SzbzpDm1wRbEXJKNJYc7V1jamUELVj_c&s=4DMMn8KoNrvfjd9HS_nXI5hLeagvDCcmeB6oFd-mcPk&e=

>and the closely following one from Thomas Schatzl summed up the concerns
>about the proposed changes.
Thank you very much for pointing out the missing items I need to take into
account.

>This is a proposal to change the memory ordering semantics of part of
>the shared GC code _not_ just the PPC64 implementation, but I have seen
>no analysis to demonstrate the correctness of such a proposal.
I do agree the necessity of demonstrating the correctness. I would try my
best for this.

Best regards,
--
Michihiro,
IBM Research - Tokyo

From:	David Holmes <david.holmes at oracle.com>
To:	Michihiro Horie <HORIE at jp.ibm.com>,
            ppc-aix-port-dev at openjdk.java.net,
            hotspot-dev at openjdk.java.net, hotspot-gc-dev at openjdk.java.net
Cc:	Hiroshi H Horii <HORII at jp.ibm.com>
Date:	2018/04/25 21:45
Subject:	Re: RFR(M): 8154736: enhancement of cmpxchg and
            copy_to_survivor for ppc64

Hi Michihiro,

On 23/04/2018 8:33 PM, Michihiro Horie wrote:
>
>
> Dear all,
>
> I would like to ask reviews on 8154736 “enhancement of cmpxchg and
> copy_to_survivor”. The change adds options to avoid expensive syncs with
> compare-and-exchange. An experiment by using SPECjbb2015 showed 6%
> improvement in critical-jOPS. This change focuses on ppc64 but would be
> potentially beneficial for aarch64.
>
> Although discussions stopped at
>
https://urldefense.proofpoint.com/v2/url?u=http-3A__mail.openjdk.java.net_pipermail_ppc-2Daix-2Dport-2Ddev_2016-2DOctober_002718.html&d=DwICJg&c=jf_iaSHvJObTbx-siA1ZOg&r=oecsIpYF-cifqq2i1JEH0Q&m=G-yYtdHSoT4SzbzpDm1wRbEXJKNJYc7V1jamUELVj_c&s=C2p8l68JKbOLCTpy4Zu5280A84QXht0U4_3Ha7QBaRc&e=

> , I would like to restart the review by taking over Hiroshi's work if the
> discussion is still open.

So the very last comment there was about not implicitly assuming
memory_order_consume, yet that has not been addressed in the proposal.

Further the discussion on hotspot-runtime-dev through September and
October was far more illuminating. I think my post here:

https://urldefense.proofpoint.com/v2/url?u=http-3A__mail.openjdk.java.net_pipermail_hotspot-2Druntime-2Ddev_2016-2DOctober_021617.html&d=DwICJg&c=jf_iaSHvJObTbx-siA1ZOg&r=oecsIpYF-cifqq2i1JEH0Q&m=G-yYtdHSoT4SzbzpDm1wRbEXJKNJYc7V1jamUELVj_c&s=4DMMn8KoNrvfjd9HS_nXI5hLeagvDCcmeB6oFd-mcPk&e=

and the closely following one from Thomas Schatzl summed up the concerns
about the proposed changes.

AFAICS the restarted proposal addresses none of those concerns but
simply takes up where the previous implementation suggestion left off.

This is a proposal to change the memory ordering semantics of part of
the shared GC code _not_ just the PPC64 implementation, but I have seen
no analysis to demonstrate the correctness of such a proposal.

David
-----

> Bug:
https://urldefense.proofpoint.com/v2/url?u=https-3A__bugs.openjdk.java.net_browse_JDK-2D8154736&d=DwICJg&c=jf_iaSHvJObTbx-siA1ZOg&r=oecsIpYF-cifqq2i1JEH0Q&m=G-yYtdHSoT4SzbzpDm1wRbEXJKNJYc7V1jamUELVj_c&s=4hpwVPathLPraOYinkDMNu4gAgivm62zURDtKyMKPe8&e=

> Webrev:
https://urldefense.proofpoint.com/v2/url?u=http-3A__cr.openjdk.java.net_-7Emhorie_8154736_webrev.08_&d=DwICJg&c=jf_iaSHvJObTbx-siA1ZOg&r=oecsIpYF-cifqq2i1JEH0Q&m=G-yYtdHSoT4SzbzpDm1wRbEXJKNJYc7V1jamUELVj_c&s=DMMm7IWjNJSRB69AbPfo-zPkhDNK8EbhxWEdT6z46k8&e=

>
> Previous review had discussions on improper log output (
>
https://urldefense.proofpoint.com/v2/url?u=http-3A__mail.openjdk.java.net_pipermail_ppc-2Daix-2Dport-2Ddev_2016-2DSeptember_002672.html&d=DwICJg&c=jf_iaSHvJObTbx-siA1ZOg&r=oecsIpYF-cifqq2i1JEH0Q&m=G-yYtdHSoT4SzbzpDm1wRbEXJKNJYc7V1jamUELVj_c&s=s0YwAXbLaVr-SrmfU4DdH87Kd4baoN7bkGA1y-fBSrQ&e=

> ). Logs can be generated properly with this change, but I would like to
ask
> if we should use “if(log) OrderAccess:acquire()” as is in webrev or more
> general approach with a call to OrderAccess:consume() with empty
> implementation on all supported platforms.
>
> Also, there were discussions on the problem of unawareness of copied obj
(
>
https://urldefense.proofpoint.com/v2/url?u=http-3A__mail.openjdk.java.net_pipermail_ppc-2Daix-2Dport-2Ddev_2016-2DOctober_002696.html&d=DwICJg&c=jf_iaSHvJObTbx-siA1ZOg&r=oecsIpYF-cifqq2i1JEH0Q&m=G-yYtdHSoT4SzbzpDm1wRbEXJKNJYc7V1jamUELVj_c&s=HmMGF6U-OQ33yEAAUBjhhdBSVzw7m9ec0oiXn8y7eS8&e=

> ). This change adds “release” in cmpxchg_pre_membar. This was discussed
in
>
https://urldefense.proofpoint.com/v2/url?u=http-3A__mail.openjdk.java.net_pipermail_ppc-2Daix-2Dport-2Ddev_2016-2DOctober_002698.html&d=DwICJg&c=jf_iaSHvJObTbx-siA1ZOg&r=oecsIpYF-cifqq2i1JEH0Q&m=G-yYtdHSoT4SzbzpDm1wRbEXJKNJYc7V1jamUELVj_c&s=mZWJvHc1jKeJlaDa1nu_vDz5FfB0WlCCnRmAOJYHLgA&e=

> .
>
> I measured SPECjbb2015 with its multi JVMs mode on a POWER8 node (for
JDK11
> , I modified MANIFEST in specjbb2015.jar to specify locations of JAXB
> related libraries). As a result, critical-jOPS improved by 6% due to this
> change.
>
> Best regards,
> --
> Michihiro,
> IBM Research - Tokyo
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/hotspot-gc-dev/attachments/20180426/4bbf48fe/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: graycol.gif
Type: image/gif
Size: 105 bytes
Desc: not available
URL: <https://mail.openjdk.org/pipermail/hotspot-gc-dev/attachments/20180426/4bbf48fe/graycol.gif>