Designing with Static Capabilities and Effects

Designing with Static Capabilities and Effects

Presentation at the Workshop on Object Capability Languages, Systems and Applications (OCAP) 2018 in Boston, MA.

A33216916f486b670031fabd1ddcf11a?s=128

Colin S Gordon

November 06, 2018
Tweet

Transcript

  1. Designing with Static Capabilities and Effects Colin S. Gordon Drexel

    University
  2. Capabilities and Effects • Capabilities exist to restrict program effects

    • Expression e can only do what it has capabilities for • If e is given no capability to do X, it cannot do X! • Can be done statically, or dynamically • Statically, object capabilities correspond to reference capabilities. • An alternative static approach to restricting effects is an effect system. • Both are useful for the same purpose – so why do we have both?
  3. Trade-Offs • If you’ve worked with these systems, you already

    know them! • But nobody talks about them • We’ll talk about trade-offs between specific systems for the same problem • Outsiders / newcomers have to learn it by trial and error • No established language to talk about these things • Let’s talk
  4. What Will We Talk About? • My experience, which seems

    generalizable • I’ve worked on reference capability systems and effect systems, sometimes separate, sometimes together! • This describes most of the research I’ve done • Drawbacks of reference capabilities, and partial work-arounds • Drawbacks of effect systems • How these drawbacks affected the design of three systems: • M# (OOPSLA 2012), JavaUI (ECOOP 2013), SJS (OOPSLA 2016)
  5. Constraining Effects with Capabilities • Reference immutability uses reference capabilities

    to restrict mutation • Can be used for data race freedom • E.g., M# (OOPSLA 2012), a precursor to Pony (AGERE 2015) • M# was the primary programming language for Midori, an attempt to productize the Singularity OS
  6. M# Reference Immutability (Simplified) writable readable immutable

  7. Exploiting Capabilities Г, ∆ Г ⊢ ⊣ Г′ ∆ ⊢

    ⊣ ∆′ Г, ∆ ⊢ || ⊣ Г′, ∆′ 𝐼𝐼𝐼𝐼𝐼𝐼𝐼𝐼𝐼𝐼 Г, Г′ Г ⊢ ⊣ Г′, : 𝑟𝑟𝑟𝑟𝑟𝑟𝑟𝑟𝑟𝑟𝑟𝑟𝑟𝑟 Г′ ⊢ ⊣ Г′, : 𝑖𝑖𝑖𝑖𝑖𝑖𝑖𝑖𝑖𝑖𝑖𝑖𝑖𝑖𝑖𝑖𝑖𝑖
  8. Using Recovery readable T RandomChoice(readable T a, readable T b)

    { ... } ... {x,y:immutable T} z = RandomChoice(x,y); {x,y:immutable T,z:readable T} {x,y,z:immutable T}
  9. Use vs. Mention {x:readable T,y:writable T,z:writable T} /* concurrent work

    with x */ y = z; /* more concurrent work with x */ {x:readable T,y:writable T,z:writable T} This cannot be parallelized! But y and z aren’t used in unsafe ways. I call this the Use-Mention Distinction after a similar concept from analytic philosophy.
  10. Effects Distinguish Use and Mention • Consider a hypothetical effect

    system, NoHeapAccess ≤ HeapAccess • Г, : , : ⊢ = ∶ 𝑢𝑢𝑢𝑢𝑢𝑢 | • This super-simple effect system could be used to parallelize “x=y” The simplicity of capabilities comes from conflating use and mention: Can’t use what you can’t even mention
  11. Working Around Use-Mention • This is a problem, but clearly

    not fatal • M# used to write most of Midori (several million LOC) • Pony is used in industry • Arguably Rust has some flavor of this • Framing / Weakening to the rescue! • Refactor the x=y elsewhere, frame away x and y and parallelize • But this only works for some problems
  12. Safe Concurrency in UIs • GUI frameworks use a distinguished

    UI thread • Background threads are used for expensive work • All UI updates *must* occur on the UI thread • Interesting reasons; see ECOOP’13 paper for discussion • Don’t do it? Exceptions, crashes, corruptions, and more. Background Thread UI Thread
  13. Statically Safe UI Concurrency • Keeping UI actions on the

    UI thread requires identifying UI elements statically • References to UI elements == reference capabilities • Idea: Don’t let background threads hold refs to UI objects! • Sound! • Also useless for existing frameworks…
  14. Sending Results from BG to UI final @UI JLabel label

    = ...; ...new Thread() { public void run() { // do really slow computation Display.asyncExec(new @UI Runnable() { public void run() { label.setText("Complete!"); } }); } }... Local on UI thread Captured as member of BG thread Captured again Used on UI thread Must distinguish use and mention! UI  background  UI data flow So we’ll just always use effects, right?
  15. Thought Experiment: Reference Immutability as an Effect System • Effects

    need to indicate variables used transitively for writing • With typical assumptions: Γ ⊢ x. f := e : U |{wr(x)} • What about let x = e1 in e2? • If e2’s effect mentions x, how do we rename? • If e1 ≡ y.f.g, we need to work back towards y • But if e2 reassigns y, or y.f, or y.f.g… we need flow-sensitive points-to analysis • Problem: Naming in the presence of mutation is hard! • Think this gets ugly? I tried to work it out for all of M#. • Think *that* sounds ugly? Wait till you see what else I tried!
  16. What Went Wrong? • Why does an effect system version

    of reference immutability get so complicated so quickly? 1. Naming things is hard (+ mutation + aliasing…) 2. The effect system has to work out on its own how variables are used • So why is the capability version simpler? • Type contexts enforce invariants • If x and y have the same type, they are treated the same • Adding capabilities to the types means the capabilities conflate what types already do – resulting in less friction for developers or designers But is it only this “kind” of system that breaks this way?
  17. Compiling JavaScript is Hard, Reason 1 of • JavaScript can

    dynamically add and remove object fields • So JavaScript breaks a fundamental assumption for optimization • This is one of many reasons JITs are used for JavaScript: • Generate code specialized to the layout of one set of objects • If the layout changes, throw away and recompile at runtime • Great performance! • Terrible memory usage! Goal: Using types, remove this pathology, and compile field accesses statically & efficiently
  18. Violating Fixed Object Layout var f = new F(); //

    f : { x:num, count : ()-->num, inc : ()-->() } f.inc(); // modifies x // F.prototype : { count : ()-->num, inc : ()-->() } F.prototype.inc() // ADDS x Calls method writing this.x on object without x!
  19. Controlling Writes, Take 1: Effects • Effects for which receiver

    fields are modified {x:num, get : ()-->num, inc : ()--[x]-->() } • Good: Fixes previous slide! • F.prototype.inc() invokes on a method w/o field x • Bad: receivers can escape methods, receivers insufficient … function() { foo(this); }
  20. Controlling Writes, Take 2: Better Effects • Effects track which

    fields are changed in *each* object {x:num, get : ()-->num, inc : ()--[this.x]-->() } • Good: Fixes original and examples with receiver escape! • Bad: need points-to information… solvable • Worse: rep exposure causes abstraction issues. No common supertype of f & g can call inc: f:{x:num, get : ()-->num, inc : ()--[this.x]-->() } g:{y:num, get : ()-->num, inc : ()--[this.y]-->() }
  21. Controlling Writes, Take 3: Existentials & Rows • First existentially

    quantify modified field { x:num, …, inc : ∃x.()--[this.x]-->() } • Then account for variable # of fields: { x:num, …, inc : ∃X.()--[wr(this.X)]-->() } • Good: The two inc signatures have a common abstraction! • Bad: Row variable disconnected from field presence… Still can’t call inc!
  22. Controlling Writes, Take 4: Existentials, Rows, and Bounds • Bounded

    existentially quantified row variables! • Good: Solves previous problem • Bad: As ugly as it sounds • Worse: Parallel problem for field reads…
  23. …Mistakes Were Made • Clearly complicated. • But is it

    inappropriately complicated? • Context required type inference • Type inference with records requires row variables • (Mitchell Wand invented rows for this purpose – LICS’87) • Type inference with records and subtyping requires row constraints • Lots of work by Cardelli, Smith, Trifinov, Pottier, and others in the 1990s • Hard to tell at the time – and the impl. still uses these! • In hindsight: Clearly too complex, inference would have had TERRIBLE error messages
  24. Key: Global Invariants Through Local Capabilities • Key concepts when

    splitting reference capability A into B and C: • B and C together permit at most what A allowed • B (resp. C) assumes interference as assumed by A, plus C (resp. B) • Used to enforce invariants (immutability or more) in: • Rely-Guarantee references (PLDI’13, TOPLAS’17) • Rely-Guarantee protocols (ECOOP’14, ECOOP’16) • All reference immutability systems (M#, Pony, Javari, OIGJ…) • Kappa (ECOOP’17) • … Compatibility is an underappreciated aspect of capabilities. We solved the fixed layout problem with compatible concrete & abstracted capabilities
  25. Wrapping Up • Static capabilities and effects both have their

    place • Capabilities permit (subjectively) simpler systems for controlling effects, but can’t distinguish use and mention • Effects are more powerful and distinguish use and mention, but data- specific effects can quickly get out hand • Effects can be a useful intermediate stage of designing a capabilities system • Using capabilities to enforce global invariants is underappreciated