506315 - avoid gcMaxMallocBytes checks on each allocation

Status: RESOLVED DUPLICATE of bug 506125

(Core :: JavaScript Engine, enhancement)

Description

[Igor Bukanov]

Currently NewGCThing on each allocation from non-empty thread-local free list still checks if gcMaxMallocBytes barrier was reached to run the last-ditch GC if so. The idea is to eliminate this check and do it only when refilling the free lists. 

The caveat here is that with long lists this could prevent running the GC after allocating, for example, few huge strings. A solution for this would be to schedule the full GC in JS_malloc when the allocator hits gcMaxMallocBytes. But that is also suboptimal since it would penalize JS_malloc with en extra check. 


+++ This bug was initially created as a clone of Bug #505315 +++

This has 2 goals:

- Make ST and MT builds more similar in behavior (easier to maintain and test).
- Allow inlining of the fast path (take item from local free list), whereas the slow path will not be inline (refill local free list). This will be a separate patch.

The patch doesn't slow down ST builds, and the extra memory use is negligible. MT builds are essentially binary-identical.

Comment 1

[Andreas Gal :gal]

JS_malloc is significantly slower than NewGCThing and hits a lock anyway, so the cost of the account will probably not be measurable (as long we do it per thread and without atomic ops).

Comment 2

[Igor Bukanov]

(In reply to comment #1)
> JS_malloc is significantly slower than NewGCThing and hits a lock anyway, so
> the cost of the account will probably not be measurable 

Strings (at least for now), objects with 4 or more properties and fast arrays are accomplished with malloc-allocated array. Thus just moving the accounting check from NewGCThing into JS_malloc may not change anything. In any case, I will try to create a patch and see how it affects benchmarks.

Comment 3

[Andreas Gal :gal]

Objects with 4 or more properties are rare. The more relevant cost is actually the scope allocation for most objects. I have patches to GC allocate both, neither with a huge speedup so far but working on it.

I have a patch that completely avoids any accounting, in either path:

https://bugzilla.mozilla.org/show_bug.cgi?id=506125

Let me know what you think. It seems to work well with the limited test cases I looked at over the weekend , but more tuning is likely needed.

Comment 4

[Andreas Gal :gal]

igor, are you currently working on this bug? 506125 is about to eliminate gcMaxMallocBytes altogether.

Comment 5

[Igor Bukanov]

(In reply to comment #4)
> igor, are you currently working on this bug? 506125 is about to eliminate
> gcMaxMallocBytes altogether.

No - the bug 506125 is the right place to address this indeed.