Bug 128570 – Removing limitation on JSLock’s lockDropDepth

• Status: RESOLVED
• Resolution: FIXED
• Component: JavaScriptCore

[Mark Lam]

Now that we’ve switched to using the C stack, we no longer need to limit the lockDropDepth to 2.

For C loop builds which still uses the separate JSStack, The JSLock will enforce ordering for re-grabbing the lock after dropping it.  Ordering is achieved by JSLock::dropAllLocks() stashing away the JSLock:: m_lockDropDepth in its dropper’s DropAllLocks::m_dropDepth before unlocking the lock.  JSLock::grabAllLocks() will ensure that JSLocks::m_lockDropDepth equals its dropper’s DropAllLocks::m_dropDepth before allowing the lock to be re-grabbed.  Otherwise, it will yield and retry again later.

[Mark Lam]

Created attachment 223785 [details]
the patch.

[Mark Lam]

Comment on attachment 223785 [details]
the patch.

View in context: https://bugs.webkit.org/attachment.cgi?id=223785&action=review

> Source/JavaScriptCore/ChangeLog:8
> +        Now that weâve switched to using the C stack, we no longer need to limit

Will fix the non-ascii character.

> Source/JavaScriptCore/ChangeLog:25
> +        JSLock, yield, and the relock it again later before retrying the check.

typo: “the relock” ==> “then relock”.

[Mark Lam]

Created attachment 223786 [details]
patch 2: fixed typos.

[Mark Lam]

Created attachment 223787 [details]
patch 3: rebased, and fixed more typo fails.

[Geoffrey Garen]

Comment on attachment 223787 [details]
patch 3: rebased, and fixed more typo fails.

View in context: https://bugs.webkit.org/attachment.cgi?id=223787&action=review

r=me

> Source/JavaScriptCore/runtime/JSLock.h:117
> +            friend class JSLock;

Let's make the accessor functions public instead of making JSLock a friend.

[Mark Lam]

Thanks for the review.  Landed in r163855: <http://trac.webkit.org/r163855>.