950044 - Add shell option to set low-memory GC settings.

Status: RESOLVED FIXED

(Core :: JavaScript Engine, defect)

Description

[Nicolas B. Pierron [:nbp]]

Unagis are not the easiest thing to test on, and many persons wonders how to reproduce results reported on arewefastyet.com, so far the way as been to ask me to do it.

So I suggest to add a shell option such as one can set the memory available on the device on check with the corresponding GC settings.  This is the way to go knowing that we are expecting different GC settings in the future which are likely to be based on the memory available on the system.

Comment 1

[Nicolas B. Pierron [:nbp]]

Attachment: bug950044-emulate-unagi.patch

This patch add a JS API function, which I intend to reuse in a near future to add more memory profiles.  In the mean time I gave it the argument given on the command line.

Sadly I have not found any mean to limit the resident memory available for the JS shell.  I experimented with setrlimit but it seems that we are eagerly mapping 500 MB of virtual memory right from the beginning.  The only solution I found seems to also rely on cgroups.

http://linux-vserver.org/Memory_Limits#Setting_memory_limits

Comment 2

[Hannes Verschore [:h4writer]]

Comment on attachment 8347329 [details] [diff] [review]
bug950044-emulate-unagi.patch

Review of attachment 8347329 [details] [diff] [review]:
-----------------------------------------------------------------

This should be made very easy to use for non-ffos devs. So straightforward and easy to use without doubting.

That's why I though you were going to make a switch:
--force-ffos-settings or --force-unagi--settings or something.
Makes it much more clear what this does. Instead of a switch based on the memory available.

Next to that I want in the documentation (so in js --help). The extra information to run even more close to unagi.
Something like: "To come closer to mimicking FFOS please run as following: 'cgroup ... && js --force-ffos-settings'"
So this should include
- What commands to give to cgroup exactly
- The infinite loop you suggested
- ...

Else this will be an extra shell option that won't be used and that would be a shame, because of the effort.

Comment 3

[Nicolas B. Pierron [:nbp]]

(In reply to Hannes Verschore [:h4writer] from comment #2)
> That's why I though you were going to make a switch:
> --force-ffos-settings or --force-unagi--settings or something.
> Makes it much more clear what this does. Instead of a switch based on the
> memory available.

FFOS is going to have different settings, and at the end these settings are going to be dependent on the memory available on the device.  Ideally to would be detected at the runtime, but I intend to make a preference in the browser.

I also thought of the --*unagi* option, but we are going to have different kind of device which have different number of core and different size of memory, so I think this would be a terrible do lie in such a way especially if I cannot reproduce the thing.

In the mean time this should reproduce most of the GC seen on an Unagi.

Comment 4

[Hannes Verschore [:h4writer]]

(In reply to Nicolas B. Pierron [:nbp] from comment #3)
> I also thought of the --*unagi* option, but we are going to have different
> kind of device which have different number of core and different size of
> memory, so I think this would be a terrible do lie in such a way especially
> if I cannot reproduce the thing.

I still would prefer "unagi" option. I know we will have different kind of devices, all with their own hacks. But better have one way to set settings and be sure they are compatible and come closely to the "real" thing. We don't need options for all devices. Only for a few, "one" in this case. Other phones will resemble this one. Also if things plays nice with this one (the lowest of the lowest). It can only get better with more memory.

I would also disable parallel-compilation etc when unagi is set.

The barrier to use this should be as low as possible. So at the end of a patch development cycle I can just add --force-unagi and it tests it. I don't want to have to "find" the right flag and afterwards looking how much memory the unagi uses, how much cores it has etc...

Comment 5

[Nicolas B. Pierron [:nbp]]

I documented the process to set-up the environment to benchmark as-if you were on a phone with a low-latency Ram and a "low"-latency hard-drive, while limiting the CPU and the RAM available.

https://developer.mozilla.org/en-US/docs/SpiderMonkey/Hacking_Tips#Benchmarking_without_a_Phone

The memory/cpu are the first variable which is going to vary between phones, even if some other might vary too.  Knowing the the number of devices would increase, that we are planning to ship on device worse than Unagis, and also better than Unagis.  I think we should just stay with an option where we describe the available memory.

PS: the Unagi has 2 modes, one with a Kernel with 256 MB, to test memory constraint environment, and another one of 512 MB.  So --*-unagi is still ambiguous.

Comment 6

[Nicolas B. Pierron [:nbp]]

https://hg.mozilla.org/integration/mozilla-inbound/rev/bc7c6b533d50

Comment 7

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/mozilla-central/rev/bc7c6b533d50

Comment 8

[Nicolas B. Pierron [:nbp]]

tiny follow-up: https://hg.mozilla.org/integration/mozilla-inbound/rev/d92206bb34a6

Comment 9

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/mozilla-central/rev/d92206bb34a6