927669 - Add some explanation about cycle collector OOM handling

Status: NEW

(Core :: Cycle Collector, defect)

Description

[Andrew McCreight [:mccr8]]

I've added a bunch of infrastructure to track OOMs in the cycle collector, by setting a flag that we check once per phase (to avoid spamming the log) at various OOM points.  Right now, we do an NS_ASSERTION and report telemetry when it happens.  It is an NS_ASSERTION because we were hitting CC OOMs frequently on TBPL, but it turns out that may just have been due to the hash table hitting its max size (bug 902922) rather than an actual OOM.  In any case, the one test suite that was causing OOMs has been fixed to not use quite so much memory, so we could probably turn it back into a fatal assertion.  Another possibility would be to crash when we OOM in release builds, but arguable it is better for the browser to hobble along into an inevitable death spiral rather than just blow up immediately.  Anyways, njn suggested this be codified in a comment in the CC somewhere so that's what this bug is about.

Comment 2

[Andrew McCreight [:mccr8]]

Oh, and another possible thing we could do when we detect OOM is to switch into some kind of special low memory mode, but that seems worse to me than crashing, given how rare it is, and how it would be annoying to have to test this entirely separate code path.

Comment 3

[Nicholas Nethercote [inactive]]

> Oh, and another possible thing we could do when we detect OOM is to switch
> into some kind of special low memory mode, but that seems worse to me than
> crashing, given how rare it is, and how it would be annoying to have to test
> this entirely separate code path.

Yeah... don't do that :)