ppc64le changes for jdk8u

Thu Apr 6 16:04:20 UTC 2017

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
] 
> 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/20170407/db115e4a/attachment-0001.html>