681815 - Release more regenerable data on GC

Status: RESOLVED WONTFIX

(Core :: JavaScript Engine, defect)

Description

[Mark Finkle (:mfinkle) (use needinfo?)]

Can we add support for freeing caches, like JIT, in response to a "memory-pressure" notification? On Android, when the app goes into the background, we send the "memory-pressure" notification in an effort to dump as much memory as possible. If we use too much memory in the background, Android will kill the application if more memory is required by a different task.

See bug 675259 for other details.

We seem to do a cycle collection and a GC currently:

http://mxr.mozilla.org/mozilla-central/source/dom/base/nsJSEnvironment.cpp#192

I don't know if that is all we can do or if we can drop more memory.

Comment 1

[David Mandelin [:dmandelin]]

AFAIK, TI purges all code when on GC, so with TI landed, this is already done. Brian, is that right?

Comment 2

[Brian Hackett [Laid off!]]

mjit code is now purged on GC, but there are other caches we don't clear on every GC.  (TI-related ones are the observed type sets for scripts and lazily constructed type objects, and there are non-TI-related ones like regexp data etc.).  Also, the jitcode is only purged if TI is enabled (it is not valid to throw away jitcode for stock JM if a script has frames on the stack), and it is currently disabled on ARM.

Comment 3

[(dormant account)]

Lets add a telemetry probe that measure how much memory is released on memory-pressure

Comment 4

[David Mandelin [:dmandelin]]

(In reply to Brian Hackett from comment #2)
> mjit code is now purged on GC, but there are other caches we don't clear on
> every GC.  (TI-related ones are the observed type sets for scripts and
> lazily constructed type objects, and there are non-TI-related ones like
> regexp data etc.).  Also, the jitcode is only purged if TI is enabled (it is
> not valid to throw away jitcode for stock JM if a script has frames on the
> stack), and it is currently disabled on ARM.

Does it make sense to clear those other caches on every GC? On ARM only, maybe?

How close are we to having TI running on ARM? That's supposed to be coming, so we shouldn't have to do anything for jitcode there.

Comment 5

[Brian Hackett [Laid off!]]

(In reply to David Mandelin from comment #4)
> Does it make sense to clear those other caches on every GC? On ARM only,
> maybe?

I think we should be aggressive about throwing away regenerable data on GC, regardless of platform.  In circumstances where throwing away data has a significant (and measured) associated cost, it doesn't need to *always* be discarded but should still be thrown away as early as we can bear it (every N seconds during a GC, say).

Comment 6

[Johnny Stenback (:jst)]

Gregor, could you look into what we can gain here and what it would take to fix this?

Comment 7

[Nicholas Nethercote [inactive]]

I see two paths here:

- With TI enabled, we just have to worry about these other caches (see comment 2).  In which case we can probably downgrade the priority on this bug.

- On ARM, we still have to worry about this.  What's the status of TI for ARM?  If it will land soon, we can downgrade this bug entirely.

Comment 8

[Brian Hackett [Laid off!]]

TI is on by default on ARM now.

Comment 9

[Nicholas Nethercote [inactive]]

In that case, I'm retitling and re-prioritizing this.

What's in the list of regenerable stuff?

- TI-related ones are the observed type sets for scripts and lazily constructed type objects
- Regexp data etc (bug 673274 covers this?)
- Property tables.

Anything else?

Comment 10

[Nicholas Nethercote [inactive]]

This is kind of being done in a piecemeal fashion, largely by bhackett, so I don't think we need this bug open.