0
Old Dog, New Tricks
A Schemer’s Guide to JavaScript
Implementations
Quasiconf 2012
Andy Wingo
wingo@igalia.com
Compiler hacker at Igalia
Contract work on language implementations
V8, JavaScriptCore
Schemer
Scheme in one slide
Parse.
Expand.
Optimize.
Codegen.
Run.
JavaScript in one slide
Pre-parse.
Run.
Parse.
Codegen.
Run.
Optimize.
Codegen.
Run.
...
On optimization
Proof-driven program transformation
Scheme: Static proofs derived from
interprocedural flow analysis
JS: D...
Barriers to optimization in
Scheme
Mutable toplevels
Separate compilation
Incomplete type information
No information on wh...
None of these inhibit
JavaScript
Assume toplevels are immutable
No real separate compilation
A wealth of type information
...
“Adaptive optimization”
Types and hot spots not known until runtime
Types and hot spots can change over time
Assumptions c...
Deoptimization for debugging
Allow multi-leveled inlining and code motion
while preserving programmer’s mental model of
ho...
Other common JS
optimizations
Unboxing
Common subexpression elimination
Loop invariant code motion (or loop peeling +
CSE)...
Different deployment models
Scheme implementations rarely run attacker- controlled code
JS: Constant blinding to prevent v...
Representation hacks
JS: NaN-boxing, sometimes
Rope strings
Dedicated regexp compilers
Matching word-at-a-time, hard to beat with a
general compiler
Lazy tear-off in JSC
A static scope implementation trick
Implementing static scope
Chains: Activations on heap (!)
❧ Closure creation: O(1) space and time
❧ Free var access: O(n) ...
Lazy tear-off in JavaScriptCore
Activations on stack
Only allocate scope chain node if closure is
captured
When control le...
Living with eval
Eval only evil if it defines new locals
var foo = 10;
function f(s){ eval(s); return foo; }
f('var foo=20...
Inline caches
Per-caller memoization, in code
Fundamental optimization for property access
Not as needed in Scheme because...
Dealing with the devil
Runtime codegen in JS has a price: C++
Most Scheme implementations are self-hosted,
with AOT compil...
JS can change the way we code
Scheme’s static implementations encourage
static programming
define-integrable
(declare (typ...
Summary
In Smart vs Lazy, Schemers always chose Smart
A bit of laziness won’t hurt
Adaptive optimization in Scheme!
questions?
❧ Work: http://www.igalia.com/compilers
❧ Words: http://wingolog.org/
❧ Slides: http://wingolog.org/pub/qc-2012...
Upcoming SlideShare
Loading in...5
×

Partial Continuations, Lessons From JavaScript and Guile in 2012 (Quasiconf 2012)

268

Published on

By Andy Wingo.

Three talks in one:

- The power of limits: Partial continuations in Scheme
- Postcards from the web: Lessons from JavaScript
- Guile in 2012: A look back at 2.0, a look forward to 2.2

The power of limits: Partial continuations in Scheme

I’ll describe what delimited continuations are, how they are better than call/cc, and then go on to demonstrate and describe an event-based cooperative threading system built with delimited continuations, showing how it makes for much clearer code. I’ll show a simple implementation of the memcached protocol.

Postcards from the web: Lessons from JavaScript

In this talk I will mention some things that I have learned about language implementations from having worked on V8 and JavaScriptCore.

Guile in 2012: A look back at 2.0, a look forward to 2.2

It will briefly summarize the 2.0 release series of Guile, how it went, what worked well and what didn’t. Then we’ll look forward to the next cycle, which is probably some 6 months away.

Published in: Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
268
On Slideshare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
1
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Transcript of "Partial Continuations, Lessons From JavaScript and Guile in 2012 (Quasiconf 2012)"

  1. 1. Old Dog, New Tricks A Schemer’s Guide to JavaScript Implementations Quasiconf 2012 Andy Wingo
  2. 2. wingo@igalia.com Compiler hacker at Igalia Contract work on language implementations V8, JavaScriptCore Schemer
  3. 3. Scheme in one slide Parse. Expand. Optimize. Codegen. Run.
  4. 4. JavaScript in one slide Pre-parse. Run. Parse. Codegen. Run. Optimize. Codegen. Run. ...
  5. 5. On optimization Proof-driven program transformation Scheme: Static proofs derived from interprocedural flow analysis JS: Dynamic proofs based on run-time observations, with ability to invalidate transformations if assumptions fail to hold
  6. 6. Barriers to optimization in Scheme Mutable toplevels Separate compilation Incomplete type information No information on what to inline call/cc
  7. 7. None of these inhibit JavaScript Assume toplevels are immutable No real separate compilation A wealth of type information Dynamic profiling identifies inline candidates No call/cc
  8. 8. “Adaptive optimization” Types and hot spots not known until runtime Types and hot spots can change over time Assumptions can be invalidated over time Adaptive optimization: speculative optimization with bailout
  9. 9. Deoptimization for debugging Allow multi-leveled inlining and code motion while preserving programmer’s mental model of how evaluation works Deoptimization already required by speculation failures
  10. 10. Other common JS optimizations Unboxing Common subexpression elimination Loop invariant code motion (or loop peeling + CSE) Range inference Register allocation Block reordering (?) But to be clear: dynamic inlining is the big one
  11. 11. Different deployment models Scheme implementations rarely run attacker- controlled code JS: Constant blinding to prevent vulnerabilities in non-JS code from using JS as a heap-spray No threads in JS
  12. 12. Representation hacks JS: NaN-boxing, sometimes Rope strings
  13. 13. Dedicated regexp compilers Matching word-at-a-time, hard to beat with a general compiler
  14. 14. Lazy tear-off in JSC A static scope implementation trick
  15. 15. Implementing static scope Chains: Activations on heap (!) ❧ Closure creation: O(1) space and time ❧ Free var access: O(n) time ❧ Not “safe for space” Displays: Activations on stack ❧ Closure creation: O(n) space and time ❧ Free var access: O(1) time ❧ Mutated variables usually boxed
  16. 16. Lazy tear-off in JavaScriptCore Activations on stack Only allocate scope chain node if closure is captured When control leaves function, tear off stack to heap, relocating pointer in scope node (no threads in JS) Memory advantages of chains with stack discipline of display closures Free var access still O(n) but inlinable
  17. 17. Living with eval Eval only evil if it defines new locals var foo = 10; function f(s){ eval(s); return foo; } f('var foo=20;') ⇒ 20 Otherwise great: a compiler available to the user Functions in which eval appears not fully optimizable: must expose symbol tables
  18. 18. Inline caches Per-caller memoization, in code Fundamental optimization for property access Not as needed in Scheme because not much polymorphism Can allow efficient generic arithmetic Can make CLOS-style generics more efficient Clojure-like sequence protocols Function application?
  19. 19. Dealing with the devil Runtime codegen in JS has a price: C++ Most Scheme implementations are self-hosted, with AOT compiler already Challenge: add adaptive optimization to existing Scheme implementation Requires good AOT compiler!
  20. 20. JS can change the way we code Scheme’s static implementations encourage static programming define-integrable (declare (type fixnum x)) (declare (safety 0) (speed 3)) (declare (usual-integrations)) include instead of load Adaptive optimization can bring back dynamicity
  21. 21. Summary In Smart vs Lazy, Schemers always chose Smart A bit of laziness won’t hurt Adaptive optimization in Scheme!
  22. 22. questions? ❧ Work: http://www.igalia.com/compilers ❧ Words: http://wingolog.org/ ❧ Slides: http://wingolog.org/pub/qc-2012js-slides.pdf ❧ Notes: http://wingolog.org/pub/qc-2012js-notes.pdf
  1. A particular slide catching your eye?

    Clipping is a handy way to collect important slides you want to go back to later.

×