为什么锁定对象使用偏置模式但已经用细锁锁定

Question

i am reading sourcecode to figure out how bias lock works. i have a question about "bulk rebias", which occured when the number of revocation of a particular data type instances. and this would increase epoch field in klass to invalidates previously held biases facilitates the bulk transfer of bias ownership from one thread to another.

and this code follows, it was written in file biasedLocking.cpp :

for (; JavaThread *thr = jtiwh.next(); ) {
      GrowableArray<MonitorInfo*>* cached_monitor_info = get_or_compute_monitor_info(thr);
      for (int i = 0; i < cached_monitor_info->length(); i++) {
        MonitorInfo* mon_info = cached_monitor_info->at(i);
        oop owner = mon_info->owner();
        markOop mark = owner->mark();
        if ((owner->klass() == k_o) && mark->has_bias_pattern()) {
          // We might have encountered this object already in the case of recursive locking
          assert(mark->bias_epoch() == prev_epoch || mark->bias_epoch() == cur_epoch, "error in bias epoch adjustment");
          owner->set_mark(mark->set_bias_epoch(cur_epoch));
        }
      }
    }

the sourcecode is here . it looks like to find all lock record which locked object's class equal to current obj's class and still biasable. if any lock record exist, its owner (lock object) must be locked with light-weight lock (thin lock) by a thread which means it should have has used bias lock and revoked by current owner, so why those code can find a lock object use bias pattern but locked with thin lock already?

updated at 2020/04/02

i write some code to test:

package tech.lovelycheng.learning.javalang.jvmtest;

import sun.misc.Unsafe;

import java.lang.reflect.Field;
import java.util.concurrent.*;

import static java.lang.System.err;

public class BIASREVOKEDANDREBIASEDTest {

private static final Unsafe U;
private static final long OFFSET = 0L;

static {

    try {
        Field unsafe = Unsafe.class.getDeclaredField("theUnsafe");
        unsafe.setAccessible(true);
        U = (Unsafe) unsafe.get(null);
    } catch (Exception e) {
        throw new IllegalStateException(e);
    }
}

public static void main(String[] args) throws ExecutionException, InterruptedException {
    ExecutorService threadPoolExecutor = Executors.newSingleThreadExecutor();

    Monitor monitor = new Monitor();

    synchronized (monitor) {

        err.println("monitor header: " + printBinaryHeader(monitor));
        //reach biasedLockingBulkRebiasThreshold
        for (int i = 0; i < 5; i++) { // to bulk rebias
            Monitor s = new Monitor();

            synchronized (s) {

            }

            threadPoolExecutor.submit(() -> {
                synchronized (s) {

                }
                return null;
            }).get();
        }
    }

    err.println("monitor header: " + printBinaryHeader(monitor));// break point here

    ss(threadPoolExecutor, monitor);


    threadPoolExecutor.shutdown();


}

private static void ss(ExecutorService threadPoolExecutor, Monitor monitor) throws InterruptedException, ExecutionException {
    threadPoolExecutor.submit(() -> {
        synchronized (monitor) {
            err.println("expect 101 at low end  monitor header: " + printBinaryHeader(monitor));
        }
    }).get();
}

private static String printHeader(Object a) {
    int word = U.getInt(a, OFFSET);
    return Integer.toHexString(word);
}

private static String printBinaryHeader(Object a) {
    int word = U.getInt(a, OFFSET);
    return Integer.toBinaryString(word);
}


private static class Monitor {
    // mutex object

    public void fn() {
    }
}

}

what i see via hsdb:

em... main thread just exit monitor, and no contention it would use bias lock certainly. why there are basicObjectMonitor on its stack?

my jvm option

-XX:+UseBiasedLocking
-XX:BiasedLockingStartupDelay=0
-Xlog:biasedlocking=trace
-XX:BiasedLockingBulkRebiasThreshold=5
-XX:BiasedLockingBulkRevokeThreshold=20
-XX:+PrintSafepointStatistics
-XX:PrintSafepointStatisticsCount=1

my jdk version : 11.0.6

Answer 1

first：MonitorObjectLock will allocated on current frame，whatever lock type the lock object use. when monitor exit, biased lock released , lock oject's markword would not change, and the owning thread's stack keeps MonitorObjectLock and its obj field is NULL. So "bulk rebias" will rebias MonitorObjectLock on stack when thread owned another biased-lock(not release and obj is not null and it is biasable) tries to own a biased but not owened lock and revocation count reach BiasedLockingBulkRebiasThreshold .