1587721 - Add memory statistics to crashes on macOS

Status: RESOLVED FIXED

(Toolkit :: Crash Reporting, enhancement)

Description

We currently write out memory statistics upon a crash only on Windows. This bug is for adding macOS support. host_statistics64() using the HOST_VM_INFO flavor seems like the only way of getting some. macOS documentation has no information on the call itself so here's the old mach documentation for host_statistics().

Comment 1

[David Teller [:Yoric] - still alive but not very active]

Ok, found some information.

Here's the data structure it fills:

struct vm_statistics64 {
	natural_t	free_count;		/* # of pages free */
	natural_t	active_count;		/* # of pages active */
	natural_t	inactive_count;		/* # of pages inactive */
	natural_t	wire_count;		/* # of pages wired down */
	uint64_t	zero_fill_count;	/* # of zero fill pages */
	uint64_t	reactivations;		/* # of pages reactivated */
	uint64_t	pageins;		/* # of pageins */
	uint64_t	pageouts;		/* # of pageouts */
	uint64_t	faults;			/* # of faults */
	uint64_t	cow_faults;		/* # of copy-on-writes */
	uint64_t	lookups;		/* object cache lookups */
	uint64_t	hits;			/* object cache hits */
	uint64_t	purges;			/* # of pages purged */
	natural_t	purgeable_count;	/* # of pages purgeable */
	/*
	 * NB: speculative pages are already accounted for in "free_count",
	 * so "speculative_count" is the number of "free" pages that are
	 * used to hold data that was read speculatively from disk but
	 * haven't actually been used by anyone so far.
	 */
	natural_t	speculative_count;	/* # of pages speculative */

	/* added for rev1 */
	uint64_t	decompressions;		/* # of pages decompressed */
	uint64_t	compressions;		/* # of pages compressed */
	uint64_t	swapins;		/* # of pages swapped in (via compression segments) */
	uint64_t	swapouts;		/* # of pages swapped out (via compression segments) */
	natural_t	compressor_page_count;	/* # of pages used by the compressed pager to hold all the compressed data */
	natural_t	throttled_count;	/* # of pages throttled */
	natural_t	external_page_count;	/* # of pages that are file-backed (non-swap) */
	natural_t	internal_page_count;	/* # of pages that are anonymous */
	uint64_t	total_uncompressed_pages_in_compressor; /* # of pages (uncompressed) held within the compressor. */
} __attribute__((aligned(8)));

Comment 2

[Gabriele Svelto [:gsvelto]]

Just glancing over the structure I'd say that we certainly want the number of free pages. If active + inactive pages represent the amount of used memory that might also be interesting. I wonder what pageins, pageouts and faults represent. If one of them (or all?) measure the amount of swapping to disk that might also be interesting.

Comment 3

[David Teller [:Yoric] - still alive but not very active]

Attachment: Bug 1587721 - Memory statistics for crashes under macOS;r?gsvelto

Comment 4

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/71af6290f436
Memory statistics for crashes under macOS;r=gsvelto

Comment 5

[Andrei Ciure[:aciure]]

Backed out changeset 71af6290f436 (bug 1587721) for causing nsExceptionHandler.cpp bustages

push that caused the backout: https://treeherder.mozilla.org/#/jobs?repo=autoland&selectedJob=279072808&resultStatus=testfailed%2Cbusted%2Cexception%2Cretry%2Cusercancel%2Crunnable&revision=71af6290f43656a1b3d978428d920e3a7dc35b12

backout: https://hg.mozilla.org/integration/autoland/rev/cb625cbe7813852a4b428f1649f7309140d3b779

Comment 6

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/c61029efd3a3
Memory statistics for crashes under macOS;r=gsvelto

Comment 7

[David Teller [:Yoric] - still alive but not very active]

Oops, just realized that we forgot to request data-review. Here we go.

What questions will you answer with this data?

Attempting to detect which crashes are related to low-memory on macOS.

Why does Mozilla need to answer these questions? Are there benefits for users? Do we need this information to address product or business requirements? Some example responses:

Because we want to fix crashes and ship Fission.

List all proposed measurements and indicate the category of data collection for each measurement, using the Firefox data collection categories on the Mozilla wiki.

• Available physical memory at the time of crash (Technical data)
• Available swap memory at the time of crash (Technical data)
• Purgeable physical memory at the time of crash (Technical data)
• Total physical memory (Technical data)

How long will this data be collected? Choose one of the following:

Forever, as part of crash monitoring.

What populations will you measure?

All macOS users (note that Windows users are already measured)

Which release channels?

All

Which countries?

All

Which locales?

All

If this data collection is default on, what is the opt-out mechanism for users?

Part of crash signatures. We don't change the mechanism for opting in/out.

Please provide a general description of how you will analyze this data.

Correlating crashes with memory conditions.

Where do you intend to share the results of your analysis?

As part of the comments and/or tests of Firefox patches fixing crashes.

Is there a third-party tool (i.e. not Telemetry) that you are proposing to use for this data collection?

Nope, this uses the crash monitor.

Comment 8

[Natalia Csoregi [:nataliaCs]]

https://hg.mozilla.org/mozilla-central/rev/c61029efd3a3

Comment 9

[Chris H-C :chutten]

PRELIMINARY NOTES:
For future Data Review requests please attach the request text to the bug and use the data-review? flag. That'll make it easier to find for future users who link to this bug, and it integrates better with Data Stewardship tooling and process.

DATA COLLECTION REVIEW RESPONSE:

Is there or will there be documentation that describes the schema for the ultimate data set available publicly, complete and accurate?

Yes. This collection is documented in its definitions file CrashAnnotations.yaml.

Is there a control mechanism that allows the user to turn the data collection on and off?

Yes. This collection is part of the crash reporting mechanism which can be controlled through Firefox's Preferences.

If the request is for permanent data collection, is there someone who will monitor the data over time?

Yes, :Yoric is responsible.

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.

Is the data collection request for default-on or default-off?

Default off for all channels. (Crash reports require opt-in)

Does the instrumentation include the addition of any new identifiers?

No.

Is the data collection covered by the existing Firefox privacy notice?

Yes.

Does there need to be a check-in in the future to determine whether to renew the data?

No. This collection is permanent.

---

Result: datareview+