ppc64le changes for jdk8u

Sat Apr 8 08:02:10 UTC 2017

Hi Hiroshi, Martin,

Would the normal way of doing this not to do the changes for jdk 10 and,
once they have proven to be stable, to backport them to 9 and 8?

8 is a stable release and 9 is closed for anything but p2 bugfixes now;
both are not ideal for this kind of development.

Also, I think the ppc-aix is too narrow a mailing list for these changes;
maybe ask hotspot-dev?

Kind Regards, Thomas

On Thu, Apr 6, 2017 at 6:04 PM, Hiroshi H Horii <HORII at jp.ibm.com> wrote:

> Hi Martin,
>
> Thank you for your comments.
>
> > 1. I think this one makes sense. Having the same platform name
> > "ppc64le" in jdk8 as in jdk9 sounds good to me.
>
> Thanks. We would like to request a change for this.
>
> > 2. and especially 5. are major feature backport changes. I'm not
> > against doing that, but it would need to be done carefully as jdk8
> > is pretty much stabilized.
>
> We would like ask a backport of 8144019.
>
> > 3. I still like the idea of optimizing forwarding in ParallelGC by
> > getting rid of the expensive heavy-weight sync instructions. I think
> > this change should be discussed in jdk10 and if we can get it
> > reviewed and pushed, it should be possible to backport it to 9u and
> > possibly to 8u.
>
> Thanks. We would like to start discussion for jdk10, first.
>
> > 4. Changing only C2 makes it inconsistent and hence incorrect.
>
> Right. I need to care C1 also.
>
> > Making support_IRIW_for_not_multiple_copy_atomic_cpu switchable on
> > PPC64 would do the job. I think this would be nice to have for
> > experiments, especially in jdk10
>
> I agree. We will start discussion for jdk10, first.
>
> Regards,
> Hiroshi
> -----------------------
> Hiroshi Horii, Ph.D.
> IBM Research - Tokyo
>
>
> "Doerr, Martin" <martin.doerr at sap.com> wrote on 2017/04/04 15:18:55:
>
> > From: "Doerr, Martin" <martin.doerr at sap.com>
> > To: Hiroshi H Horii/Japan/IBM at IBMJP, "ppc-aix-port-
> > dev at openjdk.java.net" <ppc-aix-port-dev at openjdk.java.net>
> > Cc: Michihiro Horie/Japan/IBM at IBMJP
> > Date: 2017/04/04 15:20
> > Subject: RE: ppc64le changes for jdk8u
>
> >
> > Hi Hiroshi,
> >
> > thanks for sharing your work and for providing all the webrevs. Here
> > are my comments:
> >
> > 1. I think this one makes sense. Having the same platform name
> > "ppc64le" in jdk8 as in jdk9 sounds good to me.
> >
> > 2. and especially 5. are major feature backport changes. I'm not
> > against doing that, but it would need to be done carefully as jdk8
> > is pretty much stabilized.
> >
> > 3. I still like the idea of optimizing forwarding in ParallelGC by
> > getting rid of the expensive heavy-weight sync instructions. I think
> > this change should be discussed in jdk10 and if we can get it
> > reviewed and pushed, it should be possible to backport it to 9u and
> > possibly to 8u.
> >
> > 4. Changing only C2 makes it inconsistent and hence incorrect.
> > Making support_IRIW_for_not_multiple_copy_atomic_cpu switchable on
> > PPC64 would do the job. I think this would be nice to have for
> > experiments, especially in jdk10 wrt. JEP 188: Java Memory Model Update
> [1].
> > Note that the line in Parse::do_exits() (parse1.cpp) should be changed
> from:
> > PPC64_ONLY(wrote_volatile() ||)
> > to:
> > PPC64_ONLY((support_IRIW_for_not_multiple_copy_atomic_cpu &&
> > wrote_volatile()) ||)
> > Otherwise, you'll get redundant barriers (lwsync).
> >
> > 6. Interesting. Would also be interesting to see performance
> > measurement results.
> >
> > Thanks and best regards,
> > Martin
> >
> >
> > [1] http://openjdk.java.net/jeps/188
> >
> >
> > From: ppc-aix-port-dev [mailto:ppc-aix-port-dev-bounces at openjdk.java.net
> <ppc-aix-port-dev-bounces at openjdk.java.net>]
> > On Behalf Of Hiroshi H Horii
> > Sent: Samstag, 1. April 2017 12:34
> > To: ppc-aix-port-dev at openjdk.java.net
> > Cc: Michihiro Horie <HORIE at jp.ibm.com>
> > Subject: ppc64le changes for jdk8u
> >
> > Dear all,
> >
> > In advance, I apologize that this mail has various mixed contents. I
> > may need to simplify this mail by dividing to several mails for
> > ease-of-discussion.
> >
> > I would like to introduce changes of jdk8u for ppc64le, which Michi
> > and I created. We are attempting to publish a research document
> > about performance evaluation of POWER systems based on these
> > changes. Under the license of OpenJDK, which is based on GPL, we
> > would like to open these changes.
> >
> > Some are only for jdk8u. Some are under discussion. Please give your
> > comments if you are interested in our changes. All of changesets are
> > generated based on jdk8u152-b01.
> >
> > 1. Enabled ppc64le as the default os.arch
> > When we built jdk8u on ppc64le with the latest jdk8u repository, the
> > default os.arch was ppc64. This change set ppc64le as the default
> > value of os.arch.
> > http://cr.openjdk.java.net/~horii/jdk8u_support_ppc64le/webrev/
> > http://cr.openjdk.java.net/~horii/jdk8u_support_ppc64le/hotspot/
> > http://cr.openjdk.java.net/~horii/jdk8u_support_ppc64le/jdk/
> >
> > 2. backport of CRC32 intrinsics (JDK-8131048, JDK-8164920)
> > CRC32 intrinsics was implemented and enhanced in jdk9 for ppc64le.
> > We backported these optimizations to jdk8u. There are few changed in
> > shared codes. I'm now trying to eliminate them.
> > http://cr.openjdk.java.net/~horii/8166784/webrev.00/
> >
> > 3. Elimination of memory fences before and after CAS
> > We are discussing to eliminate memory fences in ParallelGC for
> > JDK-8154736. We found that the same patterns in CMS (Probably, we
> > will be able to find them in G1). We provided changes for jdk9 in
> > the previous discussion with many supports from the community. The
> > below changes are for jdk8u for ParallelGC and CMS.
> > http://cr.openjdk.java.net/~horii/jdk8u_gcopt/webrev/
> >
> > 4. Volatile access optimization
> > In the current implementation, sync is called for each volatile read
> > and lwsync for each volatile write. With this optimization, isync is
> > called for each volatile read and lwsync and sync are called for
> > each volatile write. I'm now writing a proof
> > to validate these implementation.
> > http://cr.openjdk.java.net/~horii/jdk8u_volatilereadopt/webrev/
> >
> > 5. Tiered Compilation
> > Tiered Compilation will be introduced in jdk9 for ppc64le. We
> > backported Tiered Compilation to jdk8u. The following url includes
> > all of the above changes because we backported this feature after
> > applying them. Michi is now working to isolate dependencies in them.
> > http://cr.openjdk.java.net/~horii/jdk8u_support_tiered_ppc64le/webrev/
> > http://cr.openjdk.java.net/~horii/jdk8u_support_tiered_
> ppc64le/hotspot/webrev/
> > http://cr.openjdk.java.net/~horii/jdk8u_support_tiered_
> ppc64le/jdk/webrev/
> >
> > The above includes many changes in shared codes. We just want to add
> > tiered compilation only for ppc64le. Michi is now minimizing changes
> > in shared codes. Here is the current status.
> > http://cr.openjdk.java.net/~horii/c1backport/webrev.01/
> >
> > 6. Some bypath in JCL
> > We experimentally implemented caches of java.util.Pattern, efficient
> > String.format for a typical date format, and TreeMap optimization to
> > work around typical mistakes for not-optimized Java codes. They do
> > not guarantee specifications, I think.
> > http://cr.openjdk.java.net/~horii/jdk8u_jcl_cheat/webrev/
> >
> > I tested 5 and 6 on Ubuntu 16.04 as follows.
> >
> > $ sudo apt-get install openjdk-8-jdk openjdk-8-dbg mercurial zip
> > bzip2 unzip tar curl libnuma-dev libasound2-dev libxtst-dev
> > libfreetype6-dev libxrender-dev libcups2-dev libfreetype6-dev -y
> > $ hg clone http://hg.openjdk.java.net/jdk8u/jdk8u
> > $ cd jdk8u
> > $ sh ./get_source.sh
> > $ curl -o jdk8u.patch http://cr.openjdk.java.net/~horii/
> > jdk8u_support_tiered_ppc64le/webrev/jdk8u-dev.patch
> > $ patch -p1 < jdk8u.patch
> > $ cd hotspot
> > $ curl -o hotspot.patch http://cr.openjdk.java.net/~horii/
> > jdk8u_support_tiered_ppc64le/hotspot/webrev/hotspot.patch
> > $ patch -p1 < hotspot.patch
> > $ curl -o jdk1.patch http://cr.openjdk.java.net/~horii/
> > jdk8u_support_tiered_ppc64le/jdk/webrev/jdk.patch
> > $ curl -o jdk2.patch http://cr.openjdk.java.net/~horii/
> > jdk8u_jcl_cheat/webrev/jdk.patch
> > $ patch -p1 < jdk1.patch
> > $ patch -p1 < jdk2.patch
> > $ cd ../
> > $ sh ./configure --with-freetype-include=/usr/include/freetype2/ --
> > with-freetype-lib=/usr/lib/powerpc64le-linux-gnu/
> > $ make all
> >
> > Regards,
> > Hiroshi
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/ppc-aix-port-dev/attachments/20170408/fb24ca96/attachment.html>