Terrence Cole [:terrence] Reporter
	Description • 10 years ago

Right now, on a fresh profile, with default everything, our max pause is ~40-50ms. This appears to all come in the last slice. The GC dump is attached. Most importantly, the last slice times break down like this:

Wait Background Thread: 5.8ms,
Mark: 2.7ms
  Mark Roots: 1.6ms
Sweep: 30.4ms
  Mark During Sweeping: 8.1ms
    Mark Weak: 2.3ms
    Mark Gray: 5.5ms
    Mark Gray and Weak: 0.2ms
  Finalize Start Callback: 0.5ms
  Sweep Atoms: 3.9ms
  Sweep Compartments: 11.2ms
    Sweep Discard Code: 1.1ms
    Sweep Tables: 7.0ms
      Sweep Cross Compartment Wrappers: 0.8ms
      Sweep Base Shapes: 3.2ms
      Sweep Initial Shapes: 1.7ms
      Sweep Type Objects: 0.6ms
    Discard Analysis: 2.9ms
      Discard TI: 1.0ms
      Sweep Types: 1.9ms
  Sweep Object: 0.8ms
  Sweep String: 0.3ms
  Sweep Script: 0.6ms
  Sweep Shape: 1.9ms
  Sweep JIT code: 0.1ms
  Finalize End Callback: 1.7ms
  Deallocate: 0.5ms
End Callback: 0.2ms

	Terrence Cole [:terrence] Reporter
	Comment 1 • 10 years ago

Also, this is on a fast machine with plenty of memory and not on any particular site.

	Avi Halachmi (:avih)
	Comment 2 • 10 years ago

(In reply to Terrence Cole [:terrence] from comment #1)
> Also, this is on a fast machine with plenty of memory and not on any
> particular site.

Win 8.1 laptop, i7-4500u, 8G ram, m-c built today (opt build without debug symbols).

Also, the telemetry histograms support these values. E.g. On Firefox 34: GC_MAX_PAUSE_MS's median is 55.09 : http://telemetry.mozilla.org/#filter=nightly%2F34%2FGC_MAX_PAUSE_MS&aggregates=multiselect-all!Submissions!Mean!5th%20percentile!25th%20percentile!median!75th%20percentile!95th%20percentile&evoOver=Builds&locked=true&sanitize=true&renderhistogram=Graph

	Bill McCloskey [inactive unless it's an emergency] (:billm)
	Comment 3 • 10 years ago

I think it's important to decide up front whether the goal is to improve the empty profile use case or the lots-of-tabs users. Part of the problem with GC is that we don't have test cases that are at all representative of how users actually use the GC. areweslimyet.com is probably the closest, but it takes forever to run.

We could also consider incorporating more GC data into telemetry.

	Avi Halachmi (:avih)
	Comment 4 • 10 years ago

The goal is, IMO, to have the majority of GCs to not have slices above 10ms. Right now, from my experiments (using the patch from bug 1019611) that every 5-30ms we get a 30-60ms max pause.

I used a clean profile with various scenarios, e.g. constant simple animation on http://testufo.com, just opening and closing tabs, banana bread webgl mozilla demos, scrolling up and down on cnn.com, and others. The pattern is quite consistent- we get a max pause of ~40 ms typically every 10-30s.

Each of those - if it happens during animation - is a clearly visible dropped frame. The testufo.com site also identifies it as "not smooth".

I didn't test with multiple tabs, but I'd say that if it can't keep a simple animation consistently smooth with a single tab on a clean profile, then what chance do we have with multiple tabs and dirty profiles?

	Avi Halachmi (:avih)
	Comment 5 • 10 years ago

(In reply to Avi Halachmi (:avih) from comment #4)
> The goal is, IMO, to have the majority of GCs to not have slices above 10ms.
> Right now, from my experiments (using the patch from bug 1019611) that every
> 5-30ms we get a 30-60ms max pause.

Typo, every 5-30s there's a GC pause of 30-60ms which results in visibly dropped frame[s] if it happens to be while animating or gaming.

	Avi Halachmi (:avih)
	Comment 6 • 10 years ago

(In reply to Avi Halachmi (:avih) from comment #4)
> The goal is, IMO, to have the majority of GCs to not have slices above 10ms.

If we wanted to really define a _good_ goal, I'd say that slices should be typically not more than 5ms and, if possible, more spread apart (e.g. maybe every 5-10 frames rather than every frame).

10ms taken out of a frame could many times still cause a frame drop IMO, since it's 70% of the entire frame time, so it squeezes the frame's work quite a bit.

FWIW, I was also observing CC max slices (bug 1019101) which happen a bit more frequently than GCs (typically every 6-7s) and are shorter - typically 1-7 ms averaging about 4 I think. And on most of the CCs I couldn't notice frame drops and also testufo.com didn't detect "stutter" during CCs.

	Bill McCloskey [inactive unless it's an emergency] (:billm)
	Comment 7 • 10 years ago

OK. I have to stress, though, that 5ms is extremely ambitious. I worked on a research Java GC (Metronome) in 2006 and it managed to achieve pause times in that range, but the throughput was really bad. Another system, the Java GC from Azul is "pauseless", but it requires OS support. Also, Java GC is a lot easier than JavaScript GC, especially in a browser. I think that to get even close to 10ms would take a year or more of work.

A more reasonable goal would be to try to make GCs less frequent (with better scheduling) and smaller (per-tab rather than for all the tabs). Also, thinking ahead, electrolysis will split apart the JS heaps for the parent and the child processes. As a consequence, GCs in both processes will get faster.

	Avi Halachmi (:avih)
	Comment 8 • 10 years ago

Yeah, I didn't pretend to be able to estimate the difficulty of a 5ms goal. But both my understanding of animations and my observations with the CC pauses tell me that 5ms is a good goal to strive to.

My estimation is that 10ms taken out from a frame is likely to drop frames frequently enough - especially if we're CPU intensive like in gaming, and that consecutive frames with 10ms pause each is even more likely to (though according to Terrence we don't typically have consecutive >10ms slices - he gave me this example for slices:  [10, 1, 2, 1, 1, 3, 2, 2, 1, 39]).

I do agree, however, that having a frame or two dropped every 2 minutes is way better than every 18s - which is what I observed.

Another approach, which again I can't assess its difficulty, is to make the GCs/slices much more frequent, but only if you can make sure that typically all of them are very quick (say, 1-2 ms for the 75th percentile, and not more than 5ms for the rest upto 99th percentile).

	Terrence Cole [:terrence] Reporter
	Comment 9 • 10 years ago

Useful gc benchmarking links for Avi:
http://v8.googlecode.com/svn/branches/bleeding_edge/benchmarks/spinning-balls/index.html
http://29a.ch/2010/6/2/realtime-raytracing-in-javascript
https://videos.cdn.mozilla.net/uploads/mozhacks/flight-of-the-navigator/

(In reply to Avi Halachmi (:avih) from comment #8)
> Another approach, which again I can't assess its difficulty, is to make the
> GCs/slices much more frequent, but only if you can make sure that typically
> all of them are very quick (say, 1-2 ms for the 75th percentile, and not
> more than 5ms for the rest upto 99th percentile).

I don't understand this. What do you mean by more frequent? We're doing a slice at the top of each frame right now so more frequent would not be any different from a longer slice time.

	Avi Halachmi (:avih)
	Comment 10 • 10 years ago

(In reply to Terrence Cole [:terrence] from comment #9)
> (In reply to Avi Halachmi (:avih) from comment #8)
> > Another approach, which again I can't assess its difficulty, is to make the
> > GCs/slices much more frequent, but only if you can make sure that typically
> > all of them are very quick (say, 1-2 ms for the 75th percentile, and not
> > more than 5ms for the rest upto 99th percentile).
> 
> I don't understand this. What do you mean by more frequent? We're doing a
> slice at the top of each frame right now so more frequent would not be any
> different from a longer slice time.

Obviously more frequent than once a frame would have negative effect. I suggested an idea where the next GC would start sooner in the hope that its slices might be shorter. I can't assess how practical or useful it would be.

	Terrence Cole [:terrence] Reporter
	Comment 11 • 10 years ago

(In reply to Avi Halachmi (:avih) from comment #10)
> Obviously more frequent than once a frame would have negative effect. I
> suggested an idea where the next GC would start sooner in the hope that its
> slices might be shorter. I can't assess how practical or useful it would be.

Ah, no. The minimum length of the longest slices is proportional to the retained size, not the freed size, so this would be ineffective.

	Sylvestre Ledru [:Sylvestre]
	Comment 13 • 6 years ago

Moving to p3 because no activity for at least 24 weeks.