770200 - GC: Simplify use of GC lock

Status: RESOLVED FIXED

(Core :: JavaScript Engine, enhancement)

Description

[Jon Coppeard (:jonco)]

There's quite a bit of code scattered throughout jsgc.cpp to take/release the GC lock, but this is mostly unnecessary now that only a single thread per runtime is allowed.

The locking code can be mostly factored into the functions which interact with the background thread, simplifying the code.

Comment 1

[Jon Coppeard (:jonco)]

Attachment: Possible fix

Possible fix.

The GC lock is still used for DecommitArenas, and which I think is necessary but I'm not sure about.

Comment 2

[Gregor Wagner [:gwagner]]

That seems wrong. The lock is still needed because it's used for synchronization with the helperThread.

Comment 3

[Bill McCloskey [inactive unless it's an emergency] (:billm)]

Comment on attachment 638386 [details] [diff] [review]
Possible fix

Review of attachment 638386 [details] [diff] [review]:
-----------------------------------------------------------------

Thanks, Jon. This looks great to me.

Gregor, the lock isn't being removed here. We're just simplifying how it's acquired and released. For example, the patch acquires the lock in waitBackgroundSweepEnd, instead of in all its callers.

Comment 4

[Gregor Wagner [:gwagner]]

Oh right. I should have looked closer.

Comment 5

[Jon Coppeard (:jonco)]

Attachment: Fix for test failure on try

Fix for the following failure on the try server:

PROCESS-CRASH | file:///home/cltbld/talos-slave/test/build/jsreftest/tests/jsreftest.html?test=js1_5/extensions/regress-336409-2.js | application crashed (minidump found)

This was because JSRuntime::onOutOfMemory takes the GC lock before calling waitBackgroundSweepOrAllocEnd().

Comment 6

[Jon Coppeard (:jonco)]

https://hg.mozilla.org/integration/mozilla-inbound/rev/ed582ea30746

Comment 7

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/mozilla-central/rev/ed582ea30746