It needs to be because on 32-bit systems we can allocate new JS objects, and allocation always needs to be protected by the lock. Additionally, there were a number of race conditions when loading the JSGlobalObject from the Weak<> field of the JSManagedValue in order to get the JSContext.
The fix is to store a RefPtr<JSLock> in the JSManagedValue. The JSLock already stores a weak pointer to its corresponding VM, so this avoids a reference cycle. First we'll lock the JSLock, then check its VM pointer. If it's invalid, return nil. If it's valid, proceed as normal after initiating an APIEntryShim.
Created attachment 224266 [details]
Comment on attachment 224266 [details]
Committed r164147: <http://trac.webkit.org/changeset/164147>