783943 - Dynamically tune GC settings based on device

Status: RESOLVED INCOMPLETE

(Firefox for Android Graveyard :: General, defect)

Description

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

Bug 783912 adds some tweaked GC settings for ARMv6 devices since those might be more memory constrained than ARMv7 devices. If the effects are significant enough, we could dynamically change the settings at runtime. We need some testing to see if adding dynamic changes would be worth it.

Comment 1

[Kartikaya Gupta (email:[e-mail])]

Adding Gregor as suggested by the memshrink guys. Any ideas on how to tune the GC settings for lower memory devices would be appreciated.

Comment 2

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

Gregor - Not sure if you're still the right person for this or not, but we were curious if any GC settings would be useful for low-memory devices. Have we learned anything from the b2g low-memory work?

Comment 3

[Gregor Wagner [:gwagner]]

(In reply to Mark Finkle (:mfinkle) from comment #2)
> Gregor - Not sure if you're still the right person for this or not, but we
> were curious if any GC settings would be useful for low-memory devices. Have
> we learned anything from the b2g low-memory work?

We have b2g specific low memory events and gc triggers but I haven't touched them for a while. Nick and Kyle are probably more helpful here.

Comment 4

[Nicolas B. Pierron [:nbp]]

One thing I learned while benchmarking the GC settings on Unagis, is that this is not something we want to do blindly.  Using an automated way to set the GC settings is a wonderful foot-gun. If we do so we should back these changes by tons of tests on devices having different memory size / latencies.

If we change the GC settings, we should do that based on the total memory available and not on the availabl

I think the best way to deal with different memory profiles would be to first collect a large set of samples from mobile to desktop, and look if they are some interesting trends.  This would be a long process and vlad suggested to do that progressively by adding one function[1] responsible of setting the GC settings based on the quantity of memory available.

[1] http://dxr.mozilla.org/mozilla-central/source/js/src/jsapi.cpp?from=JS_SetGCParametersBasedOnAvailableMemory&case=true#2019

Comment 5

[Nicolas B. Pierron [:nbp]]

(In reply to Nicolas B. Pierron [:nbp] from comment #4)
> If we change the GC settings, we should do that based on the total memory
> available and not on the availabl[…]

[…]e, the reason being that we would offer a terrible user experience by calling more GC to keep background applications alive instead of just killing them and make full use of the resources available.

Comment 6

[Nicolas B. Pierron [:nbp]]

(In reply to Gregor Wagner [:gwagner] from comment #3)
> We have b2g specific low memory events and gc triggers but I haven't touched
> them for a while. Nick and Kyle are probably more helpful here.

Currently, the low-memory event is still not yet propagated through the interruption callback, it might be interesting to see how many of these events are happening while we are running JS code.

Comment 7

[Kyle Huey (Exited; not receiving bugmail, old account, do not use)]

Not sure what the question you want me to answer is ...

Comment 8

[BMO Automation]

We have completed our launch of our new Firefox on Android. The development of the new versions use GitHub for issue tracking. If the bug report still reproduces in a current version of [Firefox on Android nightly](https://play.google.com/store/apps/details?id=org.mozilla.fenix) an issue can be reported at the [Fenix GitHub project](https://github.com/mozilla-mobile/fenix/). If you want to discuss your report please use [Mozilla's chat](https://wiki.mozilla.org/Matrix#Connect_to_Matrix) server https://chat.mozilla.org and join the [#fenix](https://chat.mozilla.org/#/room/#fenix:mozilla.org) channel.