biasedLocking.hpp revision 1879
1879N/A * Copyright (c) 2005, 2010, Oracle and/or its affiliates. All rights reserved. 0N/A * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. 0N/A * This code is free software; you can redistribute it and/or modify it 0N/A * under the terms of the GNU General Public License version 2 only, as 0N/A * published by the Free Software Foundation. 0N/A * This code is distributed in the hope that it will be useful, but WITHOUT 0N/A * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or 0N/A * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License 0N/A * version 2 for more details (a copy is included in the LICENSE file that 0N/A * accompanied this code). 0N/A * You should have received a copy of the GNU General Public License version 0N/A * 2 along with this work; if not, write to the Free Software Foundation, 0N/A * Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA. 1472N/A * Please contact Oracle, 500 Oracle Parkway, Redwood Shores, CA 94065 USA 0N/A// This class describes operations to implement Store-Free Biased 0N/A// Locking. The high-level properties of the scheme are similar to 0N/A// IBM's lock reservation, Dice-Moir-Scherer QR locks, and other biased 0N/A// locking mechanisms. The principal difference is in the handling of 0N/A// recursive locking which is how this technique achieves a more 0N/A// efficient fast path than these other schemes. 0N/A// The basic observation is that in HotSpot's current fast locking 0N/A// scheme, recursive locking (in the fast path) causes no update to 0N/A// the object header. The recursion is described simply by stack 0N/A// records containing a specific value (NULL). Only the last unlock by 0N/A// a given thread causes an update to the object header. 0N/A// This observation, coupled with the fact that HotSpot only compiles 0N/A// methods for which monitor matching is obeyed (and which therefore 0N/A// can not throw IllegalMonitorStateException), implies that we can 0N/A// completely eliminate modifications to the object header for 0N/A// recursive locking in compiled code, and perform similar recursion 0N/A// checks and throwing of IllegalMonitorStateException in the 0N/A// interpreter with little or no impact on the performance of the fast 0N/A// The basic algorithm is as follows (note, see below for more details 0N/A// and information). A pattern in the low three bits is reserved in 0N/A// the object header to indicate whether biasing of a given object's 0N/A// lock is currently being done or is allowed at all. If the bias 0N/A// pattern is present, the contents of the rest of the header are 0N/A// either the JavaThread* of the thread to which the lock is biased, 0N/A// or NULL, indicating that the lock is "anonymously biased". The 0N/A// first thread which locks an anonymously biased object biases the 0N/A// lock toward that thread. If another thread subsequently attempts to 0N/A// lock the same object, the bias is revoked. 0N/A// Because there are no updates to the object header at all during 0N/A// recursive locking while the lock is biased, the biased lock entry 0N/A// code is simply a test of the object header's value. If this test 0N/A// succeeds, the lock has been acquired by the thread. If this test 0N/A// fails, a bit test is done to see whether the bias bit is still 0N/A// set. If not, we fall back to HotSpot's original CAS-based locking 0N/A// scheme. If it is set, we attempt to CAS in a bias toward this 0N/A// thread. The latter operation is expected to be the rarest operation 0N/A// performed on these locks. We optimistically expect the biased lock 0N/A// entry to hit most of the time, and want the CAS-based fallthrough 0N/A// to occur quickly in the situations where the bias has been revoked. 0N/A// Revocation of the lock's bias is fairly straightforward. We want to 0N/A// restore the object's header and stack-based BasicObjectLocks and 0N/A// BasicLocks to the state they would have been in had the object been 0N/A// locked by HotSpot's usual fast locking scheme. To do this, we bring 0N/A// the system to a safepoint and walk the stack of the thread toward 0N/A// which the lock is biased. We find all of the lock records on the 0N/A// stack corresponding to this object, in particular the first / 0N/A// "highest" record. We fill in the highest lock record with the 0N/A// object's displaced header (which is a well-known value given that 0N/A// we don't maintain an identity hash nor age bits for the object 0N/A// while it's in the biased state) and all other lock records with 0, 0N/A// the value for recursive locks. When the safepoint is released, the 0N/A// formerly-biased thread and all other threads revert back to 0N/A// HotSpot's CAS-based locking. 0N/A// This scheme can not handle transfers of biases of single objects 0N/A// from thread to thread efficiently, but it can handle bulk transfers 0N/A// of such biases, which is a usage pattern showing up in some 0N/A// applications and benchmarks. We implement "bulk rebias" and "bulk 0N/A// revoke" operations using a "bias epoch" on a per-data-type basis. 0N/A// If too many bias revocations are occurring for a particular data 0N/A// type, the bias epoch for the data type is incremented at a 0N/A// safepoint, effectively meaning that all previous biases are 0N/A// invalid. The fast path locking case checks for an invalid epoch in 0N/A// the object header and attempts to rebias the object with a CAS if 0N/A// found, avoiding safepoints or bulk heap sweeps (the latter which 0N/A// was used in a prior version of this algorithm and did not scale 0N/A// well). If too many bias revocations persist, biasing is completely 0N/A// disabled for the data type by resetting the prototype header to the 0N/A// unbiased markOop. The fast-path locking code checks to see whether 0N/A// the instance's bias pattern differs from the prototype header's and 0N/A// causes the bias to be revoked without reaching a safepoint or, 0N/A// again, a bulk heap sweep. 0N/A// Biased locking counters 0N/A // This initialization routine should only be called once and 0N/A // schedules a PeriodicTask to turn on biased locking a few seconds 0N/A // into the VM run to avoid startup time regressions 0N/A // This provides a global switch for leaving biased locking disabled 0N/A // for the first part of a run and enabling it later 0N/A // This should be called by JavaThreads to revoke the bias of an object 0N/A // These do not allow rebiasing; they are used by deoptimization to 0N/A // ensure that monitors on the stack can be migrated 0N/A // These routines are GC-related and should not be called by end 0N/A // users. GCs which do not do preservation of mark words do not need 0N/A // to call these routines. 1879N/A#
endif // SHARE_VM_RUNTIME_BIASEDLOCKING_HPP