1454024 - long running sessions result in multiple copies of (not-GC'd?) sessionrestore strings

Status: RESOLVED WORKSFORME

(Firefox :: Session Restore, defect, P3)

Description

[Nathan Froyd [:froydnj]]

Attachment: serialized sessionrestore strings

This is a spinoff of bug 1287906 comment 16: I have had multiple sessions now where the SessionWorker.js worker winds up with multiple copies of serialized sessionrestore JSON.  From my current session (~1 day old), I've attached a file with ~350MB of such serialized strings.

Explicitly invoking GC/CC appears to make the worker go away entirely (!), along with the strings.  So maybe they're just not getting GC'd properly?  That hypothesis seems possibly, especially with several tens of thousands of property name strings running about, which are also visible in about:memory for such long-running sessions...

Comment 1

[Mike de Boer [:mikedeboer]]

(In reply to Nathan Froyd [:froydnj] from comment #0)
> Explicitly invoking GC/CC appears to make the worker go away entirely (!),
> along with the strings.  So maybe they're just not getting GC'd properly? 

That the worker disappears with a GC/CC sounds quite worrying to me! I mean, I recently implemented automatic worker restarting upon postMessage failure, so this won't cause dataloss anymore, but still...

> That hypothesis seems possibly, especially with several tens of thousands of
> property name strings running about, which are also visible in about:memory
> for such long-running sessions...

Brrr, worth looking into for sure. I'd be curious to know if this is something specific to ChromeWorkers. I didn't see accidental use of global vars or anything else that might leak this data in SessionWorker.js, but I might be wrong.

What's the next step here?

Comment 2

[Nathan Froyd [:froydnj]]

(In reply to Mike de Boer [:mikedeboer] from comment #1)
> (In reply to Nathan Froyd [:froydnj] from comment #0)
> > Explicitly invoking GC/CC appears to make the worker go away entirely (!),
> > along with the strings.  So maybe they're just not getting GC'd properly? 
> 
> That the worker disappears with a GC/CC sounds quite worrying to me! I mean,
> I recently implemented automatic worker restarting upon postMessage failure,
> so this won't cause dataloss anymore, but still...

It is entirely possible that the worker got relegated to the "unimportant" section of about:memory, and I didn't comb through things carefully enough.  For instance, my current session says the worker is taking up ~144MB...but ~41.5MB of that is a single serialized sessionrestore data structure, and ArrayBuffers take up another ~41.5MB, which I assume is some kind of UTF-8 encoded version of that string.  So a good chunk of the worker memory is from these sessionrestore strings (the other big chunk is bug 1287906), and if those got GC'd, the amount of memory taken up by the worker would be pretty small...

> > That hypothesis seems possibly, especially with several tens of thousands of
> > property name strings running about, which are also visible in about:memory
> > for such long-running sessions...
> 
> Brrr, worth looking into for sure. I'd be curious to know if this is
> something specific to ChromeWorkers. I didn't see accidental use of global
> vars or anything else that might leak this data in SessionWorker.js, but I
> might be wrong.
> 
> What's the next step here?

I'm not sure.  I guess investigating the GC heuristics?  But if they mostly work and there's not a super-great STR, I think we're stuck.

Comment 3

[Eric Rahm [:erahm]]

Nathan, are you still seeing this?

Comment 4

[Nathan Froyd [:froydnj]]

I am not seeing this.  Maybe the GC heuristics got tuned, or I'm just not looking at the right time, or something.