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

[Doerr, Martin]

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.


  1.  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?
  2.  If there are a lot of deoptimizations it should make sense to investigate why this is the case so we could possibly improve that.
  3.  Is the purpose of your 2nd proposal to improve startup speed of Hadoop? Or does it take too long until re-bias happens?
  4.  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.)
  5.  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.
  6.  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<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/20200108/b04f9331/attachment.htm>