Closed Bug 916021 Opened 7 years ago Closed 6 years ago

JSRuntimes are taking too much memory in workers

Categories

(Core :: JavaScript Engine, defect, P1)

ARM
Gonk (Firefox OS)
defect

Tracking

()

RESOLVED DUPLICATE of bug 864927
mozilla28

People

(Reporter: nbp, Unassigned)

References

(Depends on 3 open bugs)

Details

(Keywords: memory-footprint, perf, Whiteboard: [c=memory p= s=2014.02.14 u=][MemShrink:P1])

Attachments

(1 file)

Attached file memory-reports
Discussing with Fabrice, the wroker are consuming way too much memory to be efficient.
B2G 1.3 (Gecko 28) is moving to used shared worker, which means that almost every application is going to use a worker at the end of 1.5.

Discussing with terrence, this might either be a probe issue or the fact that we do not decommit the memory as we are supposed to do on a shrinking GC.

Currently the attached profile show that each worker has 3 zones, one for the atoms compartment, one for the self-hosted code and one for the worker compartment, each of them are taking ~170 KB and correspond to half the memory consumed by the worker runtime.
This might be a good argument for lazy-parsing the self-hosted code. I didn't get any perf improvements out of that when I last tried (in bug 900292), so I didn't follow through and fixed all bugs, but I didn't really look into memory usage.

Another thing to look into again is the function re-lazification in bug 886193.
Depends on: 900292, 886193
Whiteboard: [MemShrink] → [MemShrink:P1]
(In reply to Till Schneidereit [:till] from comment #1)
> This might be a good argument for lazy-parsing the self-hosted code. I
> didn't get any perf improvements out of that when I last tried (in bug
> 900292), so I didn't follow through and fixed all bugs, but I didn't really
> look into memory usage.

I don't think this is related to the self-hosted code yet, I would be surprised if it is because the 3 zones are exactly the same size and I would not expect the self-hosted code to fill all 3 zones the same way.
(In reply to Nicolas B. Pierron [:nbp] from comment #2)
> I don't think this is related to the self-hosted code yet, I would be
> surprised if it is because the 3 zones are exactly the same size and I would
> not expect the self-hosted code to fill all 3 zones the same way.

Mmh, that's a good point. It might be explained by most of the self-hosting compartment's memory being shared via the shared bytecode thing. Can you check how much memory is used by that? Self-hosted code should be responsible for almost all of it.
Depends on: 921176
Depends on: 921140
Depends on: 921213
Depends on: 921224
Blocks: 941783
Blocks: 864927
Depends on: 964059
Depends on: 964057
Depends on: 941804
Depends on: 941805
Depends on: 941786
Depends on: 876173
Depends on: 944659
No longer blocks: 864927
Duplicate of this bug: 864927
Keywords: footprint, perf
Priority: -- → P1
Whiteboard: [MemShrink:P1] → [c=memory p= s= u=] [MemShrink:P1]
This bug is about memory consumption of JSRuntime in workers. Bug 864927 is about memory consumption of workers in general, plus it has much more discussion. There's no point having two levels of meta bugs, so I will dup this bug to that one.
Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → DUPLICATE
Whiteboard: [c=memory p= s= u=] [MemShrink:P1] → [c=memory p= s= u=][MemShrink:P1]
Duplicate of bug: 864927
Whiteboard: [c=memory p= s= u=][MemShrink:P1] → [c=memory p= s=2014.02.14 u=][MemShrink:P1]
You need to log in before you can comment on or make changes to this bug.