Bug 141221 – Remove concept of makeUsableFromMultipleThreads()

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

[Mark Lam]

Currently, we rely on VM::makeUsableFromMultipleThreads() being called before we start entering the VM (which means acquiring the JSLock) from different threads.  Acquisition of the JSLock will register the acquiring thread to the VM's thread registry if not added.  However, it will only do this if the VM's thread specific key has been initialized by makeUsableFromMultipleThreads().

This is fragile and also does not read intuitively because one would expect to acquire the JSLock before calling any methods on the VM.  This exactly what JSGlobalContextCreateInGroup() did (acquire the lock before calling makeUsableFromMultipleThreads()), but is wrong.  The result is that the invoking thread will not have been registered with the VM during that first entry into the VM.

The fix is to make it so that we initialize the VM's thread specific key on construction of the VM's MachineThreads registry instead of relying on makeUsableFromMultipleThreads() being called.  With this, we can eliminate makeUsableFromMultipleThreads() altogether.

[Radar WebKit Bug Importer]

<rdar://problem/19709137>

[Mark Lam]

Created attachment 245992 [details]
Perf number for the patch.

Perf numbers are neutral on aggregate.  There are some benchmark components that claim to have a significant difference, but I think that may be due to noise:

SunSpider:
   bitops-bitwise-and                                 3.7012+-0.0984     ^      3.4934+-0.1020        ^ definitely 1.0595x faster

Kraken:
   json-stringify-tinderbox                          141.180+-0.947      ^     127.461+-0.712         ^ definitely 1.1076x faster

JSRegress:
   string-char-code-at                               34.9297+-0.0626     !     35.3132+-0.2146        ! definitely 1.0110x slower
   string-repeat-arith                               83.8087+-5.9984     ^     73.9739+-1.4799        ^ definitely 1.1329x faster

I sincerely doubt that this patch could have contributed those gains.

[Mark Lam]

Created attachment 245996 [details]
the patch.

[Mark Hahnenberg]

Comment on attachment 245996 [details]
the patch.

Nice. R=me.

[Mark Lam]

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