Closed Bug 1369444 Opened 7 years ago Closed 7 years ago

Sweep the atoms table incrementally

Categories

(Core :: JavaScript: GC, enhancement)

55 Branch
enhancement
Not set
normal

Tracking

()

RESOLVED FIXED
mozilla55
Performance Impact ?
Tracking Status
firefox55 --- fixed

People

(Reporter: jonco, Assigned: jonco)

References

(Blocks 1 open bug)

Details

Attachments

(1 file)

      No description provided.
This patch splits atom sweeping into two parts - updating the atoms bitmaps and sweeping the main atoms table incrementally.

Incremental sweeping works by creating a secondary table for atoms allocated while we're sweeping the main table.  When atomising we check whether we are currently sweeping and if so check both tables, adding any new atoms to the secondary table.  We add in any new atoms at the end of sweeping.

I investigated using an ordered hash table for this instead and it worked well but increased memory usage by > 50%.  The atoms table can already take a couple of MiB so I figured we should probably not use this.  I think that approach would work well for some of the smaller tables however.

Try push: https://treeherder.mozilla.org/#/jobs?repo=try&revision=1167937e2b4948b906db97c3570d8704e3b3b33b
Attachment #8873517 - Flags: review?(sphink)
Comment on attachment 8873517 [details] [diff] [review]
bug1369444-sweep-atoms-incrementally

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

This is great! It came together nicely. I sort of want a table that encapsulates the two-table switchover stuff, but it would be a lot of boilerplate for just one usage. Maybe if we want a bunch more of these.

::: js/src/jsgc.cpp
@@ +5515,5 @@
> +        JSAtom* atom = atomsToSweep.front().asPtrUnbarriered();
> +        if (IsAboutToBeFinalizedUnbarriered(&atom))
> +            atomsToSweep.removeFront();
> +        atomsToSweep.popFront();
> +    }

The state is all local, so this could be a little simpler:

  while (!atomsToSweep.empty()) {
    if (budget.isOverBudget())
      return NotFinished;
    ...sweep the entry...
  }

@@ +5530,5 @@
> +            oomUnsafe.crash("Adding atom from secondary table after sweep");
> +    }
> +    rt->destroyAtomsAddedWhileSweepingTable();
> +
> +    maybeAtoms.reset();

won't the reset() happen in the destructor anyway?

::: js/src/vm/Runtime.h
@@ +848,5 @@
>      }
> +
> +    bool createAtomsAddedWhileSweepingTable();
> +    void destroyAtomsAddedWhileSweepingTable();
> +    js::AtomSet*& atomsAddedWhileSweeping() {

Why AtomSet*& ? I didn't seen anywhere you modified this lvalue. Why not just AtomSet*?
Attachment #8873517 - Flags: review?(sphink) → review+
(In reply to Steve Fink [:sfink] [:s:] from comment #2)
> The state is all local, so this could be a little simpler:

Good idea, tidied as suggested.

> > +    maybeAtoms.reset();
> 
> won't the reset() happen in the destructor anyway?

maybeAtoms is a reference to the sweeping state in the GCRuntime to this needs to happen here.

> Why AtomSet*& ? I didn't seen anywhere you modified this lvalue. Why not
> just AtomSet*?

Oh yeah, fixed.
Pushed by jcoppeard@mozilla.com:
https://hg.mozilla.org/integration/mozilla-inbound/rev/98b894115e89
Sweep the atoms table incrementally r=sfink
https://hg.mozilla.org/mozilla-central/rev/98b894115e89
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla55
No longer blocks: 1367727
Blocks: 1368761
Depends on: 1375445
Performance Impact: --- → ?
Whiteboard: [qf]
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: