Closed Bug 555722 Opened 10 years ago Closed 10 years ago

avoiding hold/drop for empty scopes for block and arguments objects

Categories

(Core :: JavaScript Engine, enhancement)

Other Branch
enhancement
Not set

Tracking

()

RESOLVED WONTFIX

People

(Reporter: igor, Assigned: igor)

References

Details

The bug #554626 adds a shared runtime-wide empty scope for the Argument class in addition to the shared Block empty scope. Since such scopes persists over the runtime lifetime, calls to hold/drop them could be avoided together with the associated cost of atomic increment.
Is this going to add branch tests? Perhaps better to make empty scopes GC'ed. Don't we have a bug on that (maybe for all scopes)?

/be
Igor, I have a patch to GC scopes. That avoids the hold/drop business altogether. The only problem with the patch is that we allocate more than 1.5x more memory for scopes than actual JSObjects, which upsets our GC heuristics and affects talos in some way I was never able to figure out.
(In reply to comment #2)
> Igor, I have a patch to GC scopes. That avoids the hold/drop business
> altogether. The only problem with the patch is that we allocate more than 1.5x
> more memory for scopes than actual JSObjects, which upsets our GC heuristics
> and affects talos in some way I was never able to figure out.

Have you tried to GC only empty scopes? We should not allocate many of them and these are the ones that bring the hold/drop overhead. Also in theory, since non-empty scopes are owned by the object and not shared using the GC for them just means that we would spend extra cycles marking them while not gaining match in the finalization time due to the background free.
GCing them also avoids hitting the malloc lock, which is a major expense (especially on macosx).
(In reply to comment #4)
> GCing them also avoids hitting the malloc lock, which is a major expense
> (especially on macosx).

True, but that should happen on the background thread offsetting the lock cost. Plus I suspect we should start using jemalloc directly on MacOSX. But this for another bug.
Our own GC will always be strictly faster than any malloc implementation since it uses fixed blocks.
This is no longer relevant in view of threading and scope changes.
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.