Bug 166778 - The ObjC API's JSVirtualMachine's map tables needs to be guarded by a lock.
Summary: The ObjC API's JSVirtualMachine's map tables needs to be guarded by a lock.
Alias: None
Product: WebKit
Classification: Unclassified
Component: JavaScriptCore (show other bugs)
Version: WebKit Local Build
Hardware: Unspecified Unspecified
: P2 Normal
Assignee: Mark Lam
Keywords: InRadar
Depends on:
Reported: 2017-01-06 14:50 PST by Mark Lam
Modified: 2017-01-06 15:40 PST (History)
7 users (show)

See Also:

proposed patch. (6.98 KB, patch)
2017-01-06 15:04 PST, Mark Lam
fpizlo: review+
Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Mark Lam 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.
Comment 1 Mark Lam 2017-01-06 14:52:04 PST
Comment 2 Mark Lam 2017-01-06 14:55:35 PST

This is the correct radar.  The previous one was a mistake.
Comment 3 Mark Lam 2017-01-06 15:04:29 PST
Created attachment 298230 [details]
proposed patch.
Comment 4 Filip Pizlo 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


> 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.
Comment 5 Mark Lam 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>.