Open Bug 698547 Opened 8 years ago Updated 1 year ago

Investigate if CC/GC could be postponed when user is typing or scrolling or otherwise actively interacting with the browser

Categories

(Core :: DOM: Core & HTML, defect, P5)

defect

Tracking

()

People

(Reporter: smaug, Unassigned)

References

(Depends on 1 open bug, Blocks 2 open bugs)

Details

(Whiteboard: [Snappy:P2])

This would bring back some of the old CC/GC behavior, where we didn't CC so often when
user was active.
There could be some tricky cases with something like a game, which may be generating a lot of garbage that needs to be collected, but the user is also interacting with the browser.  But it would be nice if CC/GC backed off a little while the user is typing in a text box, say.  Personally, that's when I find pauses to be the most annoying.
Hardware: x86_64 → All
Version: unspecified → Trunk
Incremental GC should reduce the GC impact of this. For the CC I would start with interruptible, and maybe go to fully incremental from there. Andrew?
Will interruptible CC by itself help with the scenario where the user is typing in the browser?  My impression was that in that situation the interruptible CC would end up not actually doing anything.

There are a few concurrent cycle collection algorithms, but getting those to work in Firefox would be a fairly long term project.  For instance, apparently in some circumstances objects that are dead can become live again, which probably would be bad for any incremental algorithm.
I still like the idea of incremental CC. You incrementally build up the graph and discover cycles. Then, for each cycle you've found, you atomically check that the graph still describes the cycle. That is, the outgoing pointers must be the same, the refcounts must be the same, and the mark bits of JS objects must still be gray. In this case, you unlink the cycle. The check and unlink part must be done atomically, but that shouldn't take too long for a single cycle (hopefully).

I'm not 100% confident that this is sound, but it seems like it would be a lot easier for us to get right than concurrent CC.
That is a very important bug for typing on Netbooks.
Just over the weekend I noticed again that the browser can't keep up with my typing.
(In reply to Andrew McCreight [:mccr8] from comment #3)
> Will interruptible CC by itself help with the scenario where the user is
> typing in the browser?  My impression was that in that situation the
> interruptible CC would end up not actually doing anything.

I guess it would help here, but we could still try to schedule the CC runs to happen at
certain times. Like when the browser is in background or something like that.

But, I guess I'll wait what kind of behavior interruptible CC will give us.


though, atm (full) GC can run while typing, so we should probably schedule that differently, 
even if we had interruptible CC.
(In reply to Bill McCloskey (:billm) from comment #4)
> I'm not 100% confident that this is sound, but it seems like it would be a
> lot easier for us to get right than concurrent CC.
Sure, we'd want to get incremental working and see how things are there before worrying about concurrent CC.  Aside from locking, I'd think that most of the big problems of incremental CC are about the same as concurrent CC.  Things like worrying about objects dying in front of us when we are building the graph, objects coming back from the dead behind us while we are checking that things are really dead, etc.
Blocks: 698919
Whiteboard: [Snappy]
This might not be so important if parts of CC can be handled in smaller step asynchronously
(bug 705582 and bug 652781 for example)
Blocks: 710372
Depends on: 712478
Whiteboard: [Snappy] → [Snappy:P2]
Blocks: 728738
No longer blocks: 728738
I'd say we should wontfix this, and just make sure CC times stay low.
(10ms CC while typing shouldn't be too bad.)
(In reply to Olli Pettay [:smaug] from comment #9)
> I'd say we should wontfix this, and just make sure CC times stay low.
> (10ms CC while typing shouldn't be too bad.)

Until we can guarantee consistently low GC/CC we need a failsafe mechanism here.
No longer blocks: 698919
Blocks: 698919
https://bugzilla.mozilla.org/show_bug.cgi?id=1472046

Move all DOM bugs that haven’t been updated in more than 3 years and has no one currently assigned to P5.

If you have questions, please contact :mdaly.
Priority: -- → P5
Component: DOM → DOM: Core & HTML
You need to log in before you can comment on or make changes to this bug.