Crom: Faster Web Browsing Using Specula9ve Execu9on James Mickens - - PowerPoint PPT Presentation

▶
crom faster web browsing using specula9ve execu9on
SMART_READER_LITE
LIVE PREVIEW

Crom: Faster Web Browsing Using Specula9ve Execu9on James Mickens - - PowerPoint PPT Presentation

Apr 09, 2023 169 likes •613 views

Crom: Faster Web Browsing Using Specula9ve Execu9on James Mickens Jeremy Elson Jon Howell Jacob R. Lorch Surfing the Web Prefetching: Web 1.0 Sta9c objects connected by declara9ve links Find prefetchable objects by traversing graph

slide-1
SLIDE 1

Crom: Faster Web Browsing Using Specula9ve Execu9on

James Mickens Jeremy Elson Jon Howell Jacob R. Lorch

slide-2
SLIDE 2

Surfing the Web

slide-3
SLIDE 3

Prefetching: Web 1.0

  • Sta9c objects connected by declara9ve links
  • Find prefetchable objects by traversing graph

<TABLE WIDTH='100%‘> <TR> <TD VALIGN='TOP' HEIGHT=60> <A HREF='/misc/winNews.htm'> Windows news </A> </TD>

slide-4
SLIDE 4

The Brave New World: Web 2.0

imgTile.ondblclick = func9on(){ map.centerTile = imgTile; map.zoomLevel++; map.fetchAndDisplayNeighbors(imgTile, map.zoomLevel); }

slide-5
SLIDE 5

New Challenges to Prefetching

  • Fetches triggered by impera9ve event handlers

– Can’t just “pre‐execute” handlers to warm cache

  • Prefetcher must understand JavaScript

– Hide side effects of specula9on un9l commit 9me

imgTile.ondblclick = func9on(){ map.centerTile = imgTile; map.zoomLevel++; map.fetchAndDisplayNeighbors(imgTile, map.zoomLevel); }

slide-6
SLIDE 6

New Challenges to Prefetching

  • Fetches oken driven by user‐generated inputs

– Binary: clicking a “download” bulon – Unconstrained: typing into a search form

  • Infeasible to speculate on all possible user inputs!

– Only speculate on constrained set of reasonable inputs

slide-7
SLIDE 7

Prior Solu9ons: Custom Code

  • Advantage: Exploit app‐specific

knowledge for . . .

– Tight code – High performance

  • Disadvantages:

– Oken difficult to write – Tightly integrated with applica9on code base (can’t be shared with

  • ther apps)
slide-8
SLIDE 8

Our Solu9on: Crom

  • A generic specula9on engine for JavaScript

– Implemented as regular JavaScript library – Requires no modifica9on to browsers

  • Applica9ons define their specula0ve intents

– Which event handlers should be specula9ve? – At what point should specula9ons occur? – Given an applica9on state, how does Crom generate specula9ve user inputs that are reasonable?

slide-9
SLIDE 9

Crom Handles The Rest ™

  • Clones browser state
  • Executes rewrilen event

handlers

  • Commits shadow state if

appropriate (fetch latency masked!)

  • Crom provides other

goodness:

– AJAX cache – Specula9ve upload API – Specula9ve r+w ops on server‐side

slide-10
SLIDE 10

Outline

  • Specula9ve Execu9on

– Cloning the browser state – Rewri9ng event handlers – Commisng specula9ve contexts – Op9miza9ons

  • Evalua9on
  • Related Work
  • Conclusions
slide-11
SLIDE 11

Adding Specula9ve Execu9on

<div id=“textDiv”> Click here to increment counter! </div> <script> var globalVar = 42; var f1 = func9on(){globalVar++;}; var f2 = func9on(){globalVar++; f1();}; var t = document.getElementById(“textDiv”); t.onclick = f2; </script> </script> Crom.makeSpecula9ve(t, “onclick”); Crom.speculate();

slide-12
SLIDE 12

Cloning the Browser State

  • Applica9on heap

– All JavaScript objects reachable from the roots of the global namespace – Apps access global namespace through global “window” variable (e.g., window.X)

  • DOM tree

– JavaScript data structure represen9ng page HTML – Each HTML tag has corresponding DOM object – App changes page visuals by modifying DOM tree

slide-13
SLIDE 13

Cloning the Applica9on Heap

  • Walk object graph and deep‐copy everything
  • Objects, primi9ves copied in obvious way . . .
  • Func9ons

– clonedF = eval(f.toString()) – Deep copy any object proper9es

var specWindow = {}; //Our shadow global namespace for(var globalProp in window) specWindow[globalProp] = Crom.deepCopy(window[globalProp]);

slide-14
SLIDE 14

Cloning the DOM Tree

<div> <div> <p> <p> <body>

Style alributes Event handlers App proper9es Style alributes Event handlers App proper9es

<div> <div> <p> <p> <body> 1) body.cloneNode() (Na9ve code: FAST) 2) Crom fix‐up traversal (Non‐na9ve code: SLOW)

Style alributes Style alributes App proper9es App proper9es Event handlers Event handlers

slide-15
SLIDE 15

Pusng It All Together

Congratula9ons!

//Create a new DOM tree var specFrame = document.createElement(“IFRAME”); specFrame.document.body = Crom.cloneDOM(); //Create a new global JavaScript namespace var specWindow = {}; for(var globalProp in window) specWindow[globalProp] = Crom.deepCopy(window[globalProp]); specWindow.window = specWindow; specWindow.document = specFrame.document;

slide-16
SLIDE 16

global_scope = {“globalVar”: 42, “f1”: func9on(){…}, “f2”: func9on(){…}}

  • JavaScript is lexically scoped

– Ac9va9on records are objects (varNamevarValue) – Resolve refs by following chain of scope objects

f2_scope = {}; var globalVar = 42; var f1 = func9on(){globalVar++;} var f2 = func9on(){globalVar++; f1();} Top‐level code Call f2() Get value of globalVar Look for globalVar FAIL Look for globalVar SUCCEED

Rewri9ng Event Handlers

slide-17
SLIDE 17

Rewri9ng Event Handlers

  • “with(obj)” inserts obj to front of scope chain

global_scope = {“globalVar”: 42, “f1”: func9on(){…}, “f2”: func9on(){…}} f2_scope = {}; Crom.rewrite = func9on(f, specWindow){ var newSrc = “func9on f(){“ + “with(specWindow){“ + f.toString() + “}}”; return eval(newSrc); }; var globalVar = 42; var f1 = func9on(){globalVar++;} var f2 = func9on(){globalVar++; f1();} var f2’ = Crom.rewrite(f2); Call f2’() Access globalVar specWindow = {“globalVar”: 42, “f1”: func9on(){…}, “f2”: func9on(){…}} Look for globalVar SUCCEED

Prevents specula9on from modifying non‐ spec global state!

slide-18
SLIDE 18

Rewri9ng Event Handlers

  • Various details (see the paper)

– Lazily rewri9ng inner func9on calls – Addi9on/dele9on of global variables – Rewri9ng closures – Local variables that shadow global ones

var f2 = func9on(){ globalVar++; f1(); }; specWindow = Crom.newContext(); var f2’ = func9on(){ with(specWindow){ var f1’ = Crom.rewrite(f1, specWindow); globalVar++; f1’(); } };

slide-19
SLIDE 19

Adding Specula9ve Execu9on

<div id=“textDiv”> Click here to increment counter! </div> <script> var globalVar = 42; var f1 = func9on(){globalVar++;} var f2 = func9on(){globalVar++; f1();} var t = document.getElementById(“textDiv”); t.onclick = f2; </script> Crom.makeSpecula9ve(t, “onclick”); Crom.speculate();

1) Clone browser state 2) Rewrite t.onclick() 3) Run t.onclick’()

slide-20
SLIDE 20

Outline

  • Specula9ve Execu9on

– Cloning the browser state – Rewri9ng event handlers – Commisng specula9ve contexts – Op9miza9ons

  • Evalua9on
  • Related Work
  • Conclusions
slide-21
SLIDE 21

Commisng Specula9ve Contexts

  • Suppose you know which one to commit . . .
  • . . . but how do you know?

//Commit the specula9ve DOM tree document.body = specWindow.document.body; //Commit the applica9on heap by commisng global heap roots for(var propName in specWindow) window[propName] = specWindow[propName]; //Clean‐up globals deleted by commisng specula9on for(var propName in window){ if(!(propName in specWindow)) delete window[propName]; }

slide-22
SLIDE 22

Start‐state Equivalence

  • When is it safe to commit a specula9ve context?

– Its start state must have been equivalent to applica9on’s current state – The specula9ve input that mutated it must be equivalent to the current (real) input

  • Applica9on defines equivalence func9on

– Hash func9on over global namespace (real or specula9ve) – Specula9ve context can only commit if its hash matches that of current (real) namespace

  • Applica9on defines mutator func9on

– Tells Crom how to change a new specula9ve context before running specula9ve event handler

slide-23
SLIDE 23

Mutator: func9on(specNamespace, specInput){ specNamespace.searchText = specInput; } State hash: func9on(globalNamespace){ return globalNamespace.searchText; } Crom.makeSpecula9ve(searchText, “onchange”, mutator, stateHash, [[“housing”], [“tulips”]]);

slide-24
SLIDE 24

S“” S“housing” S“tulips”

Crom clones Crom mutates

S“housing” S“” S“” S“tulips”

Crom speculates, warms cache

S“” S“housing”

User types “housing” Crom finds shadow state w/matching hash, commits it

S“housing”

slide-25
SLIDE 25

Start‐state Equivalence

  • What if app doesn’t specify SSE data?

– Crom throws away all specula9ons whenever any event handler executes, respeculates on everything

  • Guarantees correctness for commits . . .

– . . . but may lead to wasteful respecula9on

slide-26
SLIDE 26

Outline

  • Specula9ve Execu9on

– Cloning the browser state – Rewri9ng event handlers – Commisng specula9ve contexts – Op9miza9ons

  • Evalua9on
  • Related Work
  • Conclusions
slide-27
SLIDE 27
  • Don’t need to copy en9re heap

forest!

– Only clone trees touched by specula9on – Lazily clone them at rewrite 9me

X Z Y Y Z X Z X Z Y Z Y

Stale!

1) Pre‐specula9on 2) Specula9ve event handler touches Y.Z 3) Commit

slide-28
SLIDE 28

X Z Y Y:1 X:0 Z:2 Z:2 Y:1

Tracking Parent References

X:0 Y:1 Z:2 Y:1 Z:2 X:0 Z:2

1) Pre‐specula9on 2) Parent mapping 3) Specula9on 4) Commit: roots updated Commiled ids: 1,2 Ids of their parents: 0,1 X wasn’t commiled! Warning: stale child ref!

Y:1 Z:2 X:0

5) Commit: child refs patched

slide-29
SLIDE 29

Three Specula9on Modes

  • Full copy: clone en0re heap for each specula9on

– Always safe – May be slow – Non‐amor9zable costs

  • Checked lazy mode: lazy copying+parent tracking

– Always safe – Parent mapping costs amor9zable across specula9ons – May be slow

  • Unchecked lazy mode

– Fast – Oken safe in prac9ce, but strictly speaking . . . – . . . unsafe without checked mode refactoring

slide-30
SLIDE 30

Outline

  • Specula9ve Execu9on

– Cloning the browser state – Rewri9ng event handlers – Commisng specula9ve contexts – Op9miza9ons

  • Evalua9on
  • Related Work
  • Conclusions
slide-31
SLIDE 31

Evalua9on Applica9on

  • DHTMLGoodies Tab Manager

– Speculate on crea9ng new tab (AJAX www.cnn.com) – Embed manager code within ESPN front page

  • Can we hide Crom’s overhead in user think 9me?
slide-32
SLIDE 32

Specula9on Costs (Unchecked Lazy Mode)

25 50 75 100

C

  • p

y D O M t r e e C

  • p

y E H a n d U O R e w r i t e m u t a t

  • r

R e w r i t e h a n d l e r ( l e x i c a l a n a l y s i s + e v a l ( ) ) R e w r i t e h a n d l e r ( c l

  • n

i n g

  • b

j e c t s ) C

  • m

m i t s p e c u l a 9 v e c

  • n

t e x t

Execu&on &me (ms) 24 ms 77ms

slide-33
SLIDE 33

Specula9on Costs (Checked Lazy Mode)

Pre‐commit overhead: 182 ms Commit overhead: 5 ms

slide-34
SLIDE 34

Specula9on Costs: Autocompletor

25 50 75 100 Copy DOM tree Copy EH and UO Rewrite mutator Rewrite handler (lexical analysis + eval()) Rewrite handler (cloning objects) Commit specula9ve context

Execu&on &me (ms)

114 ms 67ms

slide-35
SLIDE 35

Specula9on Costs: Autocompletor

Pre‐specula9on overhead: 493 ms Commit overhead: 7 ms

slide-36
SLIDE 36

2 4 6 8 100 200 300 400 500 Seconds to Final Repaint Ar&ficially Induced Fetch Latency (ms) No specula9on Crom specula9on

User‐perceived Latency Reduc9on

399 ms 3427ms

slide-37
SLIDE 37

Copying the Full Heap

200 400 600 800

Time to Copy En&re App Heap (ms)

11,037 ms

slide-38
SLIDE 38

Copying the Full DOM Tree

100 200 300 400

Full DOM Tree Copy (ms)

Copying event handlers and user‐defined objects Copying DOM tree (done by na9ve code)

slide-39
SLIDE 39

Building the Parent Map

100 200 300 400

Parent mapping &me (ms)

Applica9on heap DOM tree

slide-40
SLIDE 40

Commisng the En9re DOM Tree

50 100 150

CommiFng en&re DOM tree (ms)

slide-41
SLIDE 41

Outline

  • Specula9ve Execu9on

– Cloning the browser state – Rewri9ng event handlers – Commisng specula9ve contexts – Op9miza9ons

  • Evalua9on
  • Related Work
  • Conclusions
slide-42
SLIDE 42

The Shoulders of Giants

  • Specula9on is a well‐known
  • p9miza9on

– File systems: Chang et al, Speculator – Sta9c web data: Fasterfox, HTML 5 prefetch alribute

  • Crom’s contribu9ons

– Exploit language introspec0on to have apps self‐modify – Explicitly reason about user inputs – Handle dynamically‐named content

slide-43
SLIDE 43

Conclusions

  • Prefetching non‐trivial in RIA

– Must reason about JavaScript to get fetch targets! – Current specula9ve solu9ons use custom code

  • Crom: generic JS specula9on engine

– Applica9ons express specula9ve intents – Crom automates low‐level tasks – Can reduce user‐perceived latency by order of magnitude