’scanAndLockForPut‘ in ConcurrentHashMap JDK1.7

Question

My question is about a sentence in the document:

UNlike in most methods, calls to method equals are not screened: Since traversal speed doesn't matter, we might as well help warm up the associated code and accesses as well.

I cannot understand the above sentence. Specifically what does " not screened " means? And why could we " warm up the associated code "?

scanAndLockForPut

private HashEntry<K,V> scanAndLockForPut(K key, int hash, V value) {
HashEntry<K,V> first = entryForHash(this, hash);
HashEntry<K,V> e = first;
HashEntry<K,V> node = null;
int retries = -1; // negative while locating node
while (!tryLock()) {
    HashEntry<K,V> f; // to recheck first below
    if (retries < 0) {
        if (e == null) {
            if (node == null) // speculatively create node
                node = new HashEntry<K,V>(hash, key, value, null);
            retries = 0;
        }
        else if (key.equals(e.key))
            retries = 0;
        else
            e = e.next;
    }
    else if (++retries > MAX_SCAN_RETRIES) {
        lock();
        break;
    }
    else if ((retries & 1) == 0 &&
             (f = entryForHash(this, hash)) != first) {
        e = first = f; // re-traverse if entry changed
        retries = -1;
    }
}
return node;

Answer 1

Specifically what does "not screened" means?

In this context, "screened" means checking for identity before calling equals. The left side of the following statement also taken from CHM:

if ((k = e.key) == key || (e.hash == hash && key.equals(k)))

Therefore, "not screened" means skipping identity checks.

And why could we "warm up the associated code"?

Put and get use the equals method on the key to determine a match and in the warm up case more importantly to determine what doesn't match which will always be a call to equals even if you are screening for identity. If the waiting threads all start calling key.equals which will make it 'hot' and trigger JIT compilation sooner. A faster equals method means less time holding the segment lock during a put.

It is also important to note that in JDK 8 this has all been changed.