Reduce size of Relooper's asm.js buffer

RESOLVED INCOMPLETE

Status

Firefox Graveyard
Shumway
RESOLVED INCOMPLETE
3 years ago
2 years ago

People

(Reporter: till, Assigned: till)

Tracking

Details

(Whiteboard: [MemShrink:P2])

(Assignee)

Description

3 years ago
Currently, the Relooper allocates a 4MB buffer. For 10 arbitrarily-chosen banners, the entire player compartment was 12-15MB, so the Relooper buffer is 27%-33% of the entire player's memory usage. (Or ~16-19% of total memory usage.)

I don't know how small we can make the buffer. We don't store the compiled source in it, so it should mostly depend on baseline usage + max-number-of-blocks * size-of-block.

We should probably look into ensuring that we can't blow the memory budget in any case and abort compilation, falling back to the interpreter, if we would.
We should probably investigate for j2me.js as well.
Are there any hooks in ASM.js to figure out how much of that buffer is actually used? It would be nice to add a memory reporter to make determining what the buffer size should be easier.
(Assignee)

Comment 3

3 years ago
(In reply to Eric Rahm [:erahm] from comment #2)
> Are there any hooks in ASM.js to figure out how much of that buffer is
> actually used? It would be nice to add a memory reporter to make determining
> what the buffer size should be easier.

That sounds like a great idea to me.

Luke, is this something we can do somewhat easily? Might it even be a useful devtool, perhaps?
Flags: needinfo?(luke)

Comment 4

3 years ago
Emscripten has tools for visualizing the usage of the heap dynamically.  I don't know what they are, though, so forwarding to Jukka.  The JS VM doesn't really have any idea, though.
Flags: needinfo?(luke) → needinfo?(jujjyl)

Comment 5

3 years ago
Nick Desaulniers is currently working on getting the Emscripten heap visualization up to latest - there are a few updates that need to be made to the tool to make it work reproducibly. The initial PR for that is being polished in https://github.com/kripken/emscripten/pull/3178 , following the tracing tool itself.
Flags: needinfo?(jujjyl)

Comment 6

3 years ago
Oh, and also, in an Emscripten module, one can examine the global DYNAMICTOP variable to see how much of the Emscripten HEAP has been allocated by sbrk and how much is unused. This does not give a total used memory size though, but gives a high watermark/upper bound of how much memory has been used at most by the module.
This may be less of a win than it first seems, because any unused part of the buffer will hopefully not be in RSS. (I certainly hope not, though I'm not certain.)

Having said that, the buffer still takes up address space, and on Win32 address space exhaustion does happen in practice.
Whiteboard: [MemShrink]
(In reply to Nicholas Nethercote [:njn] from comment #7)
> This may be less of a win than it first seems, because any unused part of
> the buffer will hopefully not be in RSS. (I certainly hope not, though I'm
> not certain.)

It really depends how the memory is used. Each untouched page would not be in RSS, but once the pages are touched they definitely are. So lets say the heap is used in a circular buffer manner then all of the memory would eventually be in RSS. And if we do something like calloc then you lose off the bat.
Whiteboard: [MemShrink] → [MemShrink:P2]
Assignee: nobody → till
Product: Firefox → Firefox Graveyard
Status: NEW → RESOLVED
Last Resolved: 2 years ago
Resolution: --- → INCOMPLETE
You need to log in before you can comment on or make changes to this bug.