Bug 166778

Summary: The ObjC API's JSVirtualMachine's map tables needs to be guarded by a lock.
Product: WebKit Reporter: Mark Lam <mark.lam>
Component: JavaScriptCoreAssignee: Mark Lam <mark.lam>
Status: RESOLVED FIXED    
Severity: Normal CC: fpizlo, ggaren, jfbastien, keith_miller, msaboff, saam, webkit-bug-importer
Priority: P2 Keywords: InRadar
Version: WebKit Local Build   
Hardware: Unspecified   
OS: Unspecified   
Attachments:
Description Flags
proposed patch. fpizlo: review+

Mark Lam
Reported 2017-01-06 14:50:50 PST
Now that we have a concurrent GC, access to JSVirtualMachine's m_externalObjectGraph and m_externalRememberedSet needs to guarded by a lock since both the GC marker thread and the mutator thread may access them at the same time.
Attachments
proposed patch. (6.98 KB, patch)
2017-01-06 15:04 PST, Mark Lam 		fpizlo: review+
DetailsFormatted DiffDiff
View All Add attachment proposed patch, testcase, etc.
Mark Lam
Comment 1 2017-01-06 14:52:04 PST
<rdar://problem/29759165>
Mark Lam
Comment 2 2017-01-06 14:55:35 PST
<rdar://problem/29761198> This is the correct radar. The previous one was a mistake.
Mark Lam
Comment 3 2017-01-06 15:04:29 PST
Created attachment 298230 [details] proposed patch.
Filip Pizlo
Comment 4 2017-01-06 15:16:29 PST
Comment on attachment 298230 [details] proposed patch. View in context: https://bugs.webkit.org/attachment.cgi?id=298230&action=review LGTM > Source/JavaScriptCore/API/JSVirtualMachine.mm:160 > + std::lock_guard<Lock> lock(m_externalDataMutex); It's cool to use std::lock_guard, though I've been using: auto locker = holdLock(m_externalDataMutex); recently, since holdLock() is generic over the lock type without requiring you to say what the lock type is. I don't think it's a big deal, though.
Mark Lam
Comment 5 2017-01-06 15:40:17 PST
Thanks for the review. I've updated it to use holdLock instead. Patch landed in r210458: <http://trac.webkit.org/r210458>.
Note You need to log in before you can comment on or make changes to this bug.