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

[Ting YY Wang]

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



From:	"Doerr, Martin" <martin.doerr at sap.com>
To:	Ting YY Wang <wtingsh at cn.ibm.com>,
            "ppc-aix-port-dev at openjdk.java.net"
            <ppc-aix-port-dev at openjdk.java.net>
Cc:	Michihiro Horie <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> On
Behalf Of Ting YY Wang
Sent: Dienstag, 7. Januar 2020 02:01
To: ppc-aix-port-dev at openjdk.java.net
Cc: Michihiro Horie <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





-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/ppc-aix-port-dev/attachments/20200110/10147cc4/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.java.net/pipermail/ppc-aix-port-dev/attachments/20200110/10147cc4/graycol.gif>