In a single-threaded build, JSRuntime::currentThreadOwnsOperationCallbackLock always returns true, which means that js::TriggerZoneGC always returns without triggering a GC. Even if that were not the case: Because Zone::updateMallocCounter (like JSRuntime::updateMallocCounter) only calls onTooMuchMalloc when gcMallocBytes crosses zero, not whenever it's less than zero, if that call to Zone::onTooMuchMalloc declines to actually request a GC, Zone::updateMallocCounter will never ask again. If js::TriggerZoneGC is not going to guarantee that the GC is requested, updateMallocCounter seems incorrect. (This is the same mistake described in bug 926678, but in JS::Zone, not JSRuntime.)
Created attachment 817755 [details] [diff] [review] bug926681-triggerGc Here's a patch to make single threaded builds more similar to threadsafe ones by making currentThreadOwnsOperationCallbackLock() return whether we are inside an AutoLockForOperationCallback. (The other part of this bug is addressed in bug 26678.)
Assignee: nobody → jcoppeard
Status: NEW → ASSIGNED
Attachment #817755 - Flags: review?(wmccloskey)
Comment on attachment 817755 [details] [diff] [review] bug926681-triggerGc Maybe Brian can look at this. I don't know anything about this code.
Attachment #817755 - Flags: review?(wmccloskey) → review?(bhackett1024)
Attachment #817755 - Flags: review?(bhackett1024) → review+
Status: ASSIGNED → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla27
You need to log in before you can comment on or make changes to this bug.