Optimization to improve biased locking in Hadoop Map tasks for ppc64le on jdk8u

Mon Jan 13 19:24:49 UTC 2020

Hi Felix,

re-bias functionality is already implemented.
For example, see switches BiasedLockingBulkRebiasThreshold and BiasedLockingDecayTime.

It can be true that your profiling based implementation works better for Hadoop than the existing re-biasing implementation. If so, it would be interesting to figure out why. And if the existing implementation can be configured or improved to get similar results.

I’m not using Hadoop, so I can’t evaluate it.

Best regards,
Martin

From: Ting YY Wang <wtingsh at cn.ibm.com>
Sent: Freitag, 10. Januar 2020 15:46
To: Doerr, Martin <martin.doerr at sap.com>
Cc: Michihiro Horie <HORIE at jp.ibm.com>; ppc-aix-port-dev at openjdk.java.net
Subject: Re: Optimization to improve biased locking in Hadoop Map tasks for ppc64le on jdk8u

Hello Martin,

Thank you for asking. Here is my thoughts:

1. In my experience using some simple hive query, deoptimization pretty sure happens in the hot methods which have locks, so deopt is the blocking factor for this optimization overall, otherwise we cannot easily manipulate lock states because those locks are inflated... Sorry I do not have number, but I think this is indispensable.
3. The key idea of this opt is that we are trying to make biased lock re-biasable after it has been revoked bias. Logically we can apply this opt on all Java locks. However, we may see frequent revoke bias which is bad for performance. So we cooked the second proposal to collect lock usage information, and use that information to pick out locks that are locked frequently AND contended infrequently. These locks will be good candidate to make them re-biasable.
5/6. Thank you for the suggestion. Yes, we noticed BiasedLocking is deprecated in latest jdk. By the way, I only saw it benefit Hadoop Map tasks till now, and Hadoop only runs on jdk8. Looks like the scope is not that big, so we just want to mention it here.

Thanks!

Best Regards,
Felix Wang (王挺, Ting Wang)
-----------------------------
OpenPOWER PoC/Performance
IBM GCG Systems & Technology Lab

Tel: (86-21) 6092-2393
Mobile: (86) 135-8554-9659
E-Mail: wtingsh at cn.ibm.com<mailto:wtingsh at cn.ibm.com>

[Inactive hide details for "Doerr, Martin" ---2020/01/09 01:44:49 AM---Hi Felix, first of all, thanks for sharing your prototype]"Doerr, Martin" ---2020/01/09 01:44:49 AM---Hi Felix, first of all, thanks for sharing your prototype. I haven’t looked into details, yet, but I

From: "Doerr, Martin" <martin.doerr at sap.com<mailto:martin.doerr at sap.com>>
To: Ting YY Wang <wtingsh at cn.ibm.com<mailto:wtingsh at cn.ibm.com>>, "ppc-aix-port-dev at openjdk.java.net<mailto:ppc-aix-port-dev at openjdk.java.net>" <ppc-aix-port-dev at openjdk.java.net<mailto:ppc-aix-port-dev at openjdk.java.net>>
Cc: Michihiro Horie <HORIE at jp.ibm.com<mailto:HORIE at jp.ibm.com>>
Date: 2020/01/09 01:44 AM
Subject: [EXTERNAL] RE: Optimization to improve biased locking in Hadoop Map tasks for ppc64le on jdk8u

________________________________

Hi Felix,

first of all, thanks for sharing your prototype. I haven’t looked into details, yet, but I already have a few questions and comments.

     *   Your first proposal optimizes deoptimization. Deoptimization is already slow so I wonder how big the performance gain is in comparison to revoking and re-biasing later on. Do you have performance measurements for your 2 proposals?
     *   If there are a lot of deoptimizations it should make sense to investigate why this is the case so we could possibly improve that.
     *   Is the purpose of your 2nd proposal to improve startup speed of Hadoop? Or does it take too long until re-bias happens?
     *   Impact on code size of compiled methods should be evaluated if we decide to go forward with this change. (Not so critical as long as the feature is off by default.)
     *   New features need to get contributed to jdk/jdk, not jdk8u. A problem with that may be that Oracles is planning to deprecate BiasedLocking, so it may get difficult to convince the Community to accept new optimizations.
     *   If you would like to go forward with these proposals, I suggest to post them as separate webrevs on hotspot-dev. I don’t know if anybody familiar with Hadoop reads the ppc-aix-port-dev mailing list.

Best regards,
Martin

From: ppc-aix-port-dev <ppc-aix-port-dev-bounces at openjdk.java.net<mailto:ppc-aix-port-dev-bounces at openjdk.java.net>> On Behalf Of Ting YY Wang
Sent: Dienstag, 7. Januar 2020 02:01
To: ppc-aix-port-dev at openjdk.java.net<mailto:ppc-aix-port-dev at openjdk.java.net>
Cc: Michihiro Horie <HORIE at jp.ibm.com<mailto:HORIE at jp.ibm.com>>
Subject: Optimization to improve biased locking in Hadoop Map tasks for ppc64le on jdk8u

This is not a RFR, but I want to share my prototype implementation for optimizations in the biased locking. I provide code for ppc64le due to my limited resource availability, though it should be general purpose for all the platforms in nature.

Background:
I found two interesting situations.
(1) At the beginning of deoptimization process, all biased locks are revoked, so that later they can be inflated and then moved from compiled frame to interpreter frame.
(2) Periodic lock contention occurs from background thread (e.g. TaskReporter in Hadoop). Lock bias will be revoked due to the contention, and there is less chance that lock can maintain bias.

Proposal:
(1) Enhance deoptimization to keep locks biased.
Once vframeArray is created by create_vframeArray, it is guaranteed there will be no safepoint until fields are rematerialized. So this is a equal guarantee that lock biased state will be preserved during this period, and it is possible to simply move lock from compiled frame to interpreter frame without inflate (Thanks to the comments in BasicLock::move_to()).
(2) Eagerly manipulate to biased state for target lock states if possible. To determine the target locks, my approach uses profiling to identify locks that are hot and accessed by a single thread.

Prototype implementation:
http://cr.openjdk.java.net/~mhorie/bl/webrev/

Let me know if this hack can benefit your workload, and any comments are welcomed. Thanks!

Best Regards,
Felix Wang (王挺, Ting Wang)
-----------------------------
OpenPOWER PoC/Performance
IBM GCG Systems & Technology Lab

Tel: (86-21) 6092-2393
Mobile: (86) 135-8554-9659
E-Mail: wtingsh at cn.ibm.com<mailto:wtingsh at cn.ibm.com>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/ppc-aix-port-dev/attachments/20200113/6c175d17/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.gif
Type: image/gif
Size: 105 bytes
Desc: image001.gif
URL: <https://mail.openjdk.java.net/pipermail/ppc-aix-port-dev/attachments/20200113/6c175d17/image001-0001.gif>