Nika Layzell [:nika] (ni? for response) Reporter
	Description • 6 years ago

Currently we're persisting SessionStorage in an in-memory database. Unfortunately, we still end up writing this data out to disk, as it is saved by Session Restore in the Session Restore JSON file so it can be restored if the browser crashes.

It would be more efficient if we instead stored it double-keyed by some sort of session ID, and then perform occasional GCs of the unused keys (such as after reading the Session REstore database on startup). This would allow us to reduce the amount of work Session Restore has to do, while also potentially simplifying the SessionStorage APIs.

	Nika Layzell [:nika] (ni? for response) Reporter
	Comment 1 • 6 years ago

Marion, could you ask someone to throw some feedback as to how they feel about this idea?

This has some impact on how bug 1445459	ends up being implemented for fission.

	Marion Daly [:mdaly]
	Comment 2 • 6 years ago

:janv can you give Nika feedback on this plan? I think it has merit but I don't know if it will lead to any increased efficiencies.

	Jan Varga [:janv]
	Comment 3 • 6 years ago

Nika, if I understand your proposal correctly, you want to completely unplug SessionStorage from the Session Restore database and handle crash recovery by persisting SessionStorage like we persist LocalStorage, is that right ?
Well, I think I like this idea.
Actually, I would be more than happy to do this change since it touches multiple areas that I'm involved with.

I don't know all the session restore internals yet, could you tell me more about session ID ?
Do we need to keep multiple versions of SessionStorage data for the same origin ?
Could we just persist SessionStorage like LocalStorage and then at startup load data for SessionStorage as part of crash recovery ?

This can also affect the new LocalStorage implementation which is about to land soon.
Originally, I assumed that SessionStorage would stay separate from LocalStorage which influenced my decisions regarding directory and filenames, either in the source code or in the storage area in user's profile directory.

Andrew, I think we might need to investigate this before landing new LS.

	Nika Layzell [:nika] (ni? for response) Reporter
	Comment 4 • 6 years ago

(In reply to Jan Varga [:janv] from comment #3)
> Nika, if I understand your proposal correctly, you want to completely unplug
> SessionStorage from the Session Restore database and handle crash recovery
> by persisting SessionStorage like we persist LocalStorage, is that right ?

Yup, that's what I was planning to do here.

> Well, I think I like this idea.
> Actually, I would be more than happy to do this change since it touches
> multiple areas that I'm involved with.

🎉

> I don't know all the session restore internals yet, could you tell me more
> about session ID ?

I don't believe that we currently associate a unique serializable ID with each SessionStore entry, but it wouldn't be hard to add one which was visible to SessionStorage in both processes & was used to save & restore this information.

> Do we need to keep multiple versions of SessionStorage data for the same
> origin ?

No, we should not need to do this. SessionStorage is stored separately from history entries. Currently it looks something like:

    "https://www.messenger.com^userContextId=6": { "sp_pi": "..." }

and instead we would just store a single ID for the entries which we'd use to look up from SessionStorage when restoring.

We'd also probably have some sort of cleanup system where we'd request a list of all SessionStorage IDs and would choose to either retain or discard each set.

> Could we just persist SessionStorage like LocalStorage and then at startup
> load data for SessionStorage as part of crash recovery ?

Yup! That'd be pretty great :-)