Your SlideShare is downloading. ×
Partial Continuations, Lessons From JavaScript and Guile in 2012 (Quasiconf 2012)
Upcoming SlideShare
Loading in...5

Thanks for flagging this SlideShare!

Oops! An error has occurred.

Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

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


Published on

By Andy Wingo. …

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
  • Be the first to comment

  • Be the first to like this

No Downloads
Total Views
On Slideshare
From Embeds
Number of Embeds
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

No notes for slide


  • 1. Old Dog, New Tricks A Schemer’s Guide to JavaScript Implementations Quasiconf 2012 Andy Wingo
  • 2. Compiler hacker at Igalia Contract work on language implementations V8, JavaScriptCore Schemer
  • 3. Scheme in one slide Parse. Expand. Optimize. Codegen. Run.
  • 4. JavaScript in one slide Pre-parse. Run. Parse. Codegen. Run. Optimize. Codegen. Run. ...
  • 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. Barriers to optimization in Scheme Mutable toplevels Separate compilation Incomplete type information No information on what to inline call/cc
  • 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. “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. 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. 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. 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. Representation hacks JS: NaN-boxing, sometimes Rope strings
  • 13. Dedicated regexp compilers Matching word-at-a-time, hard to beat with a general compiler
  • 14. Lazy tear-off in JSC A static scope implementation trick
  • 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. 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. 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. 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. 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. 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. Summary In Smart vs Lazy, Schemers always chose Smart A bit of laziness won’t hurt Adaptive optimization in Scheme!
  • 22. questions? ❧ Work: ❧ Words: ❧ Slides: ❧ Notes: