Open Bug 927669 Opened 6 years ago Updated 5 years ago

Add some explanation about cycle collector OOM handling

Categories

(Core :: XPCOM, defect)

defect
Not set

Tracking

()

People

(Reporter: mccr8, Unassigned)

References

Details

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.
Duplicate of this bug: 664280
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.
> 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 :)
You need to log in before you can comment on or make changes to this bug.