1638669 - Share bytecode with Workers

Status: NEW

(Core :: JavaScript Engine, enhancement, P3)

Description

[Ted Campbell [:tcampbell]]

After Bug 1638470, there will be no JSAtoms left in SharedScriptData and we will be able to move the shared table to the parent-Runtime and share with workers as well.

This table is already thread-safe. The one consideration is what should be done about the sweeping the table since each runtime sweeps right now.

Another thing to consider is if we should just have a global atomic counter that is update each time a BaseScript finalizer drops refcount low enough. This could be an estimate of the number of bytes that would be saved and we could avoid scanning the table every GC. (It is an estimate because the ref count may increase before we sweep. Still would be better than today!)

While here, we should remove this old comment: https://searchfox.org/mozilla-central/rev/2c619e2a98d75c40a0aba2c19bb768659ac53860/js/src/gc/GC.cpp#6190-6195

Comment 1

[Ted Campbell [:tcampbell]]

Hmm.. this may be more complicated than I thought. The AutoLockScriptData avoids taking the mutex if there are no off-thread compiles pending. If we share the table with workers, we would have to always take the lock. I'm not sure what the perf impact is if we do this or if there are other strategies.

Comment 2

[Nicolas B. Pierron [:nbp]]

We have 2 options:
1/ parse and share.
2/ index and (share or parse+register).

Currently the first one is already implemented as a memory saving approach, as it used to be done in the past to save memory after loading the same script in a different runtime, such as for workers.

However, I think this approach is not sufficient, as the intent is also to remove the parse-time. While this might not be important on desktop, this apparently matters a lot on mobile, and especially with JSM.

Thus I think we should probably increase the amount of information stored in ImmutableScriptData, or add an additional structure to reference source atoms locations, such that we can fully recover a JSScript given only the ScriptSource and immutable non-GC data.

(or this is just me not fully understanding what we currently have)

Comment 3

[Nicolas B. Pierron [:nbp]]

Unassigning my-self as I will look at more important issues first.