Closed Bug 1580227 Opened 7 months ago Closed 6 months ago

Add 'effectiveness' telemetry for GC

Categories

(Core :: JavaScript: GC, task, P1)

task

Tracking

()

RESOLVED FIXED
mozilla71
Tracking Status
firefox71 --- fixed

People

(Reporter: jonco, Assigned: jonco)

Details

Attachments

(2 files)

To help improve GC scheduling we can calculate some 'effectiveness' score for a collection, so we can attempt to compare different scheduling policies and check changes to our scheduling policy don't regress.

I'm thinking this should be memory freed per second or similar.

In Bug 1519298 I wanted to measure both the memory freed but also the memory allocated during a GC and report it to the profiler.

We might start of with 100MB allocated, A GC may free 40MB but 20MB may have been allocated while that GC runs and now the heap is 20MB big. The GC was "effective" at freeing 40MB but we should also note that it only managed to "keep up with" the mutator by 20MB.

(In reply to Paul Bone [:pbone] from comment #1)
The point of this is to add telemetry to see how we're doing at scheduling GCs in the wild, although this information could be added to the profiler too. And by scheduling I mean when we decide to start a GC. The issue of whether the GC can keep up with the mutator is more about when we run subsequent slices and how long for. We probably need better (or at least different) names for these things.

Requesting data review for new telemetry.

Attachment #9092056 - Flags: data-review?(chutten)
Comment on attachment 9092056 [details]
data_collection_request.txt

Load-balancing to Megan.
Attachment #9092056 - Flags: data-review?(chutten) → data-review?(mmccorquodale)

Hi, can I get a review for this please?

Flags: needinfo?(mmccorquodale)

So sorry, this got lost in my queue. Will do now.

Comment on attachment 9092056 [details]
data_collection_request.txt

	1.	Is there or will there be documentation that describes the schema for the ultimate data set in a public, complete, and accurate way?
This will be documented in the probe dictionary. 
2. Is there a control mechanism that allows the user to turn the data collection on and off? 
Yes, by opting out of telemetry collection. 
	3.	If the request is for permanent data collection, is there someone who will monitor the data over time?
Jon Coppeard will monitor.
4. Using the category system of data types on the Mozilla wiki, what collection type of data do the requested measurements fall under?
Category 1, Technical data.

5. Is the data collection request for default-on or default-off?
Default on. 
6. Does the instrumentation include the addition of any new identifiers?
No new identifiers. 
7. Is the data collection covered by the existing Firefox privacy notice? 
Yes. 

	8.	Does there need to be a check-in in the future to determine whether to renew the data? 
No.
9. Does the data collection use a third-party collection tool?
No.

--- 
data-review +

Note - to ensure that this probe collects data in release you must include the "releaseChannelCollection": "opt-out" key in the probe definition.
Flags: needinfo?(mmccorquodale)
Attachment #9092056 - Flags: data-review?(mmccorquodale) → data-review+
Attachment #9092053 - Attachment description: Bug 1580227 - Add GC 'effectiveness' score to help understand whether we trigger GC at the right time r?pbone → Bug 1580227 - Add GC 'effectiveness' score to help understand whether we trigger GC at the right time r=pbone data-review=mmccorquodale
Pushed by jcoppeard@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/6b0aaa84ee8e
Add GC 'effectiveness' score to help understand whether we trigger GC at the right time r=pbone data-review=mmccorquodale
Status: NEW → RESOLVED
Closed: 6 months ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla71

(In reply to Jon Coppeard (:jonco) from comment #2)

(In reply to Paul Bone [:pbone] from comment #1)
The point of this is to add telemetry to see how we're doing at scheduling GCs in the wild, although this information could be added to the profiler too. And by scheduling I mean when we decide to start a GC. The issue of whether the GC can keep up with the mutator is more about when we run subsequent slices and how long for. We probably need better (or at least different) names for these things.

That makes sense/I agree they're different things. My thoughts were more about maybe there's code they could share.

You need to log in before you can comment on or make changes to this bug.