945166 - Merge JS bytecode, jit code, type tree and shape tree of iframes of embedded YouTube videos.

Status: REOPENED

(Core :: JavaScript Engine, defect)

Description

[Thinker Li [:sinker]]

Story:
It is very common to embed video from YouTube on pages.  For some web sites a page may embed several YouTube videos.  Every embedded video create an iframe.  These iframes are supposed to load the same set of JS codes.  Bytecode, jit code, type tree and shape tree should be exactly/or almost the same.  They could be shared, but it is not in reality.

Solution:
Bytecode is exactly the same for the same JS file.  For jit code, type tree and shape tree, they are very similar among the iframes, but may be not exactly the same.  Although there are minor different, spidermonkey is designed to handle these different among JSObjects to generate multiple verions of jit code.  So, it is possible to share jit code, type tree and shape tree among iframes of embedded YouTube videos.

Comment 1

[Ting-Yuan Huang]

Attachment: memory-reports

The sizes of data structures are very close to each other; The style-sheets are exactly of the same size:

1,082,776 B (02.34%) ── style-sheets

Comment 2

[Andreas Gal :gal]

I think we have a similar bug already.

Comment 3

[Thinker Li [:sinker]]

Yes! After your reminding, I find bug 846173 mentioned exactly the same issue, but no solution or any progress there.  I suggest to identify iframes of this type by comparing the digest and URI of JS code.  Then, the iframe could reuse script, bytecode, jit code, type objects and shapes of another iframe once the document is full loaded.  For b2g is very different from desktop, in the case of youtube, shapes are major duplication among iframes (0.56MB per iframe).

style-sheets would be modified by the JS code, it needs some kind of COW that is not easy to implement. (map the list of the same pages to multiple location privately?)

Comment 4

[Andreas Gal :gal]

Dito here. We can't block days before FC date on brand new features.

Comment 5

[Boris Zbarsky [:bzbarsky]]

Don't we share the bytecode already?  I certainly thought we did...

Comment 6

[Till Schneidereit [:till]]

(In reply to Boris Zbarsky [:bz] from comment #5)
> Don't we share the bytecode already?  I certainly thought we did...

We do: bug 679940. The other things are interesting, but much harder to implement, as pointers to per-compartment data structures are baked in.

Comment 7

[Joe Cheng [:jcheng] (please needinfo)]

triage: this bug is not likely to be in time for 1.3. clear the flag and work on this on trunk

Comment 8

[Joe Cheng [:jcheng] (please needinfo)]

triage: remove [tarako]. not going to be in time for tarako timeframe

Comment 9

[Benjamin Bouvier [:bbouvier] (inactive)]

Mass-closing JS bugs for which the platform is Gonk (Firefox OS), since Firefox OS is gone. Feel free to re-open if still valid.

(plus it seems partially addressed by the bytecode cache)

Comment 10

[Boris Zbarsky [:bzbarsky]]

This still seems valid, and should be made easier in terms of the per-compartment stuff mentioned above by the work Jason is doing...