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

Like this? Share it with your network

Share

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

  • 399 views
Uploaded 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.

More in: Technology
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
    Be the first to like this
No Downloads

Views

Total Views
399
On Slideshare
398
From Embeds
1
Number of Embeds
1

Actions

Shares
Downloads
1
Comments
0
Likes
0

Embeds 1

http://www.slideee.com 1

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 1. Old Dog, New Tricks A Schemer’s Guide to JavaScript Implementations Quasiconf 2012 Andy Wingo
  • 2. wingo@igalia.com 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: 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