MotionsToContinue - Revision history

Jrose at 05:45, 14 January 2010

2010-01-14T05:45:15Z

Gafter at 21:23, 24 September 2009

2009-09-24T21:23:27Z

Gafter at 21:18, 24 September 2009

2009-09-24T21:18:36Z

Jrose at 20:45, 24 September 2009

2009-09-24T20:45:27Z

Jrose: New page: We had a lively ad hoc workshop after Lukas Stadler's talk ended in a vigorous Q&A session. Key design points for continuations: * full or scoped * restartability: one-shot or repeated ...

2009-09-24T20:44:17Z

New page: We had a lively ad hoc workshop after Lukas Stadler's talk ended in a vigorous Q&A session. Key design points for continuations: * full or scoped * restartability: one-shot or repeated ...

New page

We had a lively ad hoc workshop after Lukas Stadler's talk ended in a vigorous Q&A session.

Key design points for continuations:
* full or scoped
* restartability: one-shot or repeated restart
* reflectability: opaque, read-only, serializable (forgeable!)
* mobility: thread-bound, JVM-bound, mobile

These design choices are all more or less independent.

Rose: We're crazy (e.g, 2nd Life style continuations) but we're also willing to take short-term gains.

The Hottest Use Case: Generators and coroutines may be viewed as scoped, one-shot, opaque, and thread-bound.

The Room: We want coroutines & generators ASAP. That's your short-term goal, please.

Coroutines can be thread-bound, and swapped like Green Threads. But, in order to give them (and parallel generators!?) more room to grow into our multicore future, they must not be CPU-bound. This involves either (a) a non-thread-bound view of coroutines, or (b) a way to split threads into "fibers" (cf. Ruby).

Discussion: How much "fiber" do we need to be healthy here? Would it be best to layer fibers (at the Java level) onto thread pools? Or is there a JVM or hardware abstraction that's better? Must specify interactions with thread locals, thread locks, backtraces, (implicitly) thread critical sections, etc. Fibers seem to want "miniature" versions of all these. Basic problem is that threads have grown to do too much; we need a strength-reduced thread.

Hard Problem: How does existing code (bytecodes!) interact with continuations? Throw-out is OK, but restart is seemingly intractable. The result is that continuation restarting only works for code within a "silo" (e.g, code compiled by my Scheme bytecode compiler). Good model: Scheme's DYNAMIC-WIND. Key idea is bracketing; for every finalization there is a paired initialization; re-entry of a continuation runs the initialization. Problem: It's impossible to extract these retroactively from Java (source or bytecode).

Some (Bloch, Gafter?) claimed that the compatibility problem makes restartable continuations an impractical goal in our ecosystem, since no solution interoperates with existing JDK code. John: Distinguish between three kinds of code: 1. older stack frames outside a continuation, 2. stack frames crossed (especially resumed) by continuations, 3. younger stack frames which enter and exit without touching continuatiosn. 1 and 3 have no compatibility problem, 2 are a minority in the JDK, since they correspond to higher-order functions of some sort.

Code in category 2 is of course the problem. Glimmer of partial solution: If a Java method has no exception handlers, it is almost certainly bracket-free (or else originally buggy!). Stadler's solution is to accept siloing and annotate the category 2 methods; a continuation which fails to "see" an annotation will refuse to restart an unknown method, throwing an error instead.

Design Problem: What is the status of JVM locals w.r.t. continuations? John: They are a stable property of the continuation. Neal: Unless the continuation respects the mutable nature of JVM locals (and allows changes to them to persist into restarts) the continuation mechanism is useless. John: Useless = overstatement. Compiler writers will do what they always have, statically evacuate mutable variables to the heap, so as not to be caught up directly in the continuation. Neal, Josh: That's siloing, so it's wrong. ...Back to the previous Hard Problem.

← Older revision		Revision as of 05:45, 14 January 2010
Line 1:		Line 1:
−	We had a lively ad hoc workshop after Lukas Stadler's talk ended in a vigorous Q&A session.	+	We had a lively ad hoc workshop after [http://wiki.jvmlangsummit.com/JVM_Continuations Lukas Stadler's talk] ended in a vigorous Q&A session.

	Key design points for continuations:		Key design points for continuations:

← Older revision		Revision as of 21:23, 24 September 2009
Line 34:		Line 34:

	A simpler problem that illustrates a more typical use case is generating/iterating over the nodes of a binary tree. Using threads or true coroutines, this can be done in linear time. A common failing of coroutine implementations is that they require between O(n log n) and O(n^2) time for this use case. That appears to be a limitation of the JVM prototype for continuations too. While that doesn't totally undermine their utility, it does make them impractical for many applications.		A simpler problem that illustrates a more typical use case is generating/iterating over the nodes of a binary tree. Using threads or true coroutines, this can be done in linear time. A common failing of coroutine implementations is that they require between O(n log n) and O(n^2) time for this use case. That appears to be a limitation of the JVM prototype for continuations too. While that doesn't totally undermine their utility, it does make them impractical for many applications.
		+
		+	Asynchronous programming is another large class of use cases, also rooted in the desire to minimize the number of threads (again, because threads are expensive). Assuming one can't simply make threads cheap enough, it is possible to build a library framework on top of coroutines that enable writing asynchronous code in the synchronous style (i.e., the system performs the inversion of control for you, under the covers). Such frameworks have been built for C# and other languages using the language's iterator methods as corotuines.

@@ Line 22: / Line 22: @@
 Some (Bloch, Gafter?) claimed that the compatibility problem makes restartable continuations an impractical goal in our ecosystem, since no solution interoperates with existing JDK code.  John:  Distinguish between three kinds of code:  1. older stack frames outside a continuation, 2. stack frames crossed (especially resumed) by continuations, 3. younger stack frames which enter and exit without touching continuatiosn.  1 and 3 have no compatibility problem, 2 are a minority in the JDK, since they correspond to higher-order functions of some sort.
 Code in category 2 is of course the problem.  Glimmer of partial solution:  If a Java method has no exception handlers, it is almost certainly bracket-free (or else originally buggy!).  Stadler's solution is to accept siloing and annotate the category 2 methods; a continuation which fails to "see" an annotation will refuse to restart an unknown method, throwing an error instead.
 ; Design Problem:  What is the status of JVM locals w.r.t. continuations?  John: They are a stable property of the continuation.  Neal:  Unless the continuation respects the mutable nature of JVM locals (and allows changes to them to persist into restarts) the continuation mechanism is useless.  John:  Useless = overstatement.  Compiler writers will do what they always have, statically evacuate mutable variables to the heap, so as not to be caught up directly in the continuation.  Neal, Josh:  That's siloing, so it's wrong.  ...Back to the previous Hard Problem.

@@ Line 2: / Line 2: @@
 Key design points for continuations:
- * full or scoped
+* full or scoped
- * restartability: one-shot or repeated restart
+* restartability: one-shot or repeated restart
- * reflectability: opaque, read-only, serializable (forgeable!)
+* reflectability: opaque, read-only, serializable (forgeable!)
- * mobility: thread-bound, JVM-bound, mobile
+* mobility: thread-bound, JVM-bound, mobile
 These design choices are all more or less independent.
-Rose: We're crazy (e.g, 2nd Life style continuations) but we're also willing to take short-term gains.
+; The Hottest Use Case: Generators and coroutines may be viewed as scoped, one-shot, opaque, and thread-bound.
-The Hottest Use Case: Generators and coroutines may be viewed as scoped, one-shot, opaque, and thread-bound.
+Rose said: We're crazy (e.g, 2nd Life style continuations) but we're also willing to take short-term gains.
-The Room:  We want coroutines & generators ASAP.  That's your short-term goal, please.
+The Room said:  We want coroutines & generators ASAP.  That's your short-term goal, please.
 Coroutines can be thread-bound, and swapped like Green Threads.  But, in order to give them (and parallel generators!?) more room to grow into our multicore future, they must not be CPU-bound.  This involves either (a) a non-thread-bound view of coroutines, or (b) a way to split threads into "fibers" (cf. Ruby).
-Discussion:  How much "fiber" do we need to be healthy here?  Would it be best to layer fibers (at the Java level)  onto thread pools?  Or is there a JVM or hardware abstraction that's better?  Must specify interactions with thread locals, thread locks, backtraces, (implicitly) thread critical sections, etc.  Fibers seem to want "miniature" versions of all these.  Basic problem is that threads have grown to do too much; we need a strength-reduced thread.
+; Discussion:  How much "fiber" do we need to be healthy here?  Would it be best to layer fibers (at the Java level)  onto thread pools?  Or is there a JVM or hardware abstraction that's better?  Must specify interactions with thread locals, thread locks, backtraces, (implicitly) thread critical sections, etc.  Fibers seem to want "miniature" versions of all these.  Basic problem is that threads have grown to do too much; we need a strength-reduced thread.
-Hard Problem:  How does existing code (bytecodes!) interact with continuations?  Throw-out is OK, but restart is seemingly intractable.  The result is that continuation restarting only works for code within a "silo" (e.g, code compiled by my Scheme bytecode compiler).  Good model: Scheme's DYNAMIC-WIND.  Key idea is bracketing; for every finalization there is a paired initialization; re-entry of a continuation runs the initialization.  Problem:  It's impossible to extract these retroactively from Java (source or bytecode).
+; Hard Problem:  How does existing code (bytecodes!) interact with continuations?  Throw-out is OK, but restart is seemingly intractable.  The result is that continuation restarting only works for code within a "silo" (e.g, code compiled by my Scheme bytecode compiler).  Good model: Scheme's DYNAMIC-WIND.  Key idea is bracketing; for every finalization there is a paired initialization; re-entry of a continuation runs the initialization.  Problem:  It's impossible to extract these retroactively from Java (source or bytecode).
 Some (Bloch, Gafter?) claimed that the compatibility problem makes restartable continuations an impractical goal in our ecosystem, since no solution interoperates with existing JDK code.  John:  Distinguish between three kinds of code:  1. older stack frames outside a continuation, 2. stack frames crossed (especially resumed) by continuations, 3. younger stack frames which enter and exit without touching continuatiosn.  1 and 3 have no compatibility problem, 2 are a minority in the JDK, since they correspond to higher-order functions of some sort.
@@ Line 25: / Line 25: @@
 Code in category 2 is of course the problem.  Glimmer of partial solution:  If a Java method has no exception handlers, it is almost certainly bracket-free (or else originally buggy!).  Stadler's solution is to accept siloing and annotate the category 2 methods; a continuation which fails to "see" an annotation will refuse to restart an unknown method, throwing an error instead.
-Design Problem:  What is the status of JVM locals w.r.t. continuations?  John: They are a stable property of the continuation.  Neal:  Unless the continuation respects the mutable nature of JVM locals (and allows changes to them to persist into restarts) the continuation mechanism is useless.  John:  Useless = overstatement.  Compiler writers will do what they always have, statically evacuate mutable variables to the heap, so as not to be caught up directly in the continuation.  Neal, Josh:  That's siloing, so it's wrong.  ...Back to the previous Hard Problem.
+; Design Problem:  What is the status of JVM locals w.r.t. continuations?  John: They are a stable property of the continuation.  Neal:  Unless the continuation respects the mutable nature of JVM locals (and allows changes to them to persist into restarts) the continuation mechanism is useless.  John:  Useless = overstatement.  Compiler writers will do what they always have, statically evacuate mutable variables to the heap, so as not to be caught up directly in the continuation.  Neal, Josh:  That's siloing, so it's wrong.  ...Back to the previous Hard Problem.