From wtingsh at cn.ibm.com Tue Jan 7 01:00:56 2020 From: wtingsh at cn.ibm.com (Ting YY Wang) Date: Tue, 7 Jan 2020 09:00:56 +0800 Subject: Optimization to improve biased locking in Hadoop Map tasks for ppc64le on jdk8u Message-ID: 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: From martin.doerr at sap.com Wed Jan 8 17:43:55 2020 From: martin.doerr at sap.com (Doerr, Martin) Date: Wed, 8 Jan 2020 17:43:55 +0000 Subject: Optimization to improve biased locking in Hadoop Map tasks for ppc64le on jdk8u In-Reply-To: References: Message-ID: 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 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 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: From wtingsh at cn.ibm.com Fri Jan 10 14:45:57 2020 From: wtingsh at cn.ibm.com (Ting YY Wang) Date: Fri, 10 Jan 2020 22:45:57 +0800 Subject: Optimization to improve biased locking in Hadoop Map tasks for ppc64le on jdk8u In-Reply-To: References: Message-ID: 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" To: Ting YY Wang , "ppc-aix-port-dev at openjdk.java.net" Cc: Michihiro Horie 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 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 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: -------------- next part -------------- A non-text attachment was scrubbed... Name: graycol.gif Type: image/gif Size: 105 bytes Desc: not available URL: From martin.doerr at sap.com Mon Jan 13 19:24:49 2020 From: martin.doerr at sap.com (Doerr, Martin) Date: Mon, 13 Jan 2020 19:24:49 +0000 Subject: Optimization to improve biased locking in Hadoop Map tasks for ppc64le on jdk8u In-Reply-To: References: Message-ID: 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 Sent: Freitag, 10. Januar 2020 15:46 To: Doerr, Martin Cc: Michihiro Horie ; 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 [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" > To: Ting YY Wang >, "ppc-aix-port-dev at openjdk.java.net" > Cc: Michihiro Horie > 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 > 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 > 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: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.gif Type: image/gif Size: 105 bytes Desc: image001.gif URL: