If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

Add a way to detect huge strings more easily

RESOLVED WORKSFORME

Status

()

Core
JavaScript Engine
RESOLVED WORKSFORME
4 years ago
2 years ago

People

(Reporter: mccr8, Unassigned)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [MemShrink:P2])

(Reporter)

Description

4 years ago
It kind of sucks that in bug 884394 it required days of Blake's time to track down some huge strings creation in an app.  Using huge strings in apps and Gaia is quite common, so we'll see this come up over and over again.  jorendorff suggested that in these situations we should throw an exception rather than just crash.

I think one way to do this would be to add some kind of pref to set a threshold for huge string creation.  If you try to create a string that is over 100kb or 1mb or whatever you want, then it would throw rather than blow up.  Thus an app developer could figure out where the giant strings are being created and deal with it using the normal dev tools.
(Reporter)

Comment 1

4 years ago
(See bug 923185 for an alternate modest-proposal solution.)
My vote for a relatively low threshold (eg 100k) to make sure people hit that limit early, and for throwing.
We'd probably want to throw only if the big string is created in one hit, rather than if it's created via concatenation?
Just to confirm, this would only happen for Gaia apps? I doubt such a low limit is acceptable on the web.
(Reporter)

Comment 5

4 years ago
I'm not sure we want it on by default even in B2G.  The use case I'm thinking of is that a developer has an app that is OOMing in some circumstance, and they want to figure out why.  They'd flip a pref or set an option in a developer tool, then run their test case again, and see if they had a giant string pop up somewhere.

It would be kind of cool if a page/app could opt-in to limited length strings, which would allow all of Gaia to have some kind of limit if so desired.  It might be a bit tricky because strings are per-zone, but we don't want to leak information across compartments within a zone, so the limit would have to be per-compartment.  Otherwise, pages could communicate across domains by setting limits in one domain and checking them in another by creating strings.
Whiteboard: [MemShrink] → [MemShrink:P2]
(Reporter)

Comment 6

2 years ago
I think the notable strings stuff in about:memory, and the strings analysis scripts I wrote for GC logs, are good enough.
Status: NEW → RESOLVED
Last Resolved: 2 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.