Generalize exceptions to events #49

KarlSchimpf · 2018-02-26T23:13:38Z

Change the exception handling proposal to use a more general notion of "events", so that it will be easier to generalize the proposal when yeild/resume events are added.

… into KarlSchimpf-fix

rossberg · 2018-02-27T10:20:54Z

proposals/Level-1.md

-Data types are extended to have a new `except_ref` type. The representation of
-an exception value is left to the host VM.
+Data types are extended to have a new `except_ref` type, that refers to an
+exception. The representation of an exception is left to the embedder.


"is left to the implementation"

rossberg · 2018-02-27T10:27:54Z

proposals/Level-1.md

-When an exception value is thrown, the host VM searches for nearest enclosing
-try block body that execution is in. That try block is called the _catching_ try
-block.
+When an exception value is thrown, the embedder searches for the nearest


"the embedder searches" - it's the Wasm VM. How about: "When an exception is thrown, the active try block entered last is called the catching try block."

rossberg · 2018-02-27T10:28:49Z

proposals/Level-1.md

-stack is popped back to the size the operand stack had when the try block was
-entered, and then the values of the caught exception value is pushed onto the
-stack.
+As expected, it is left to the embedder to define how WebAssembly exceptions are


This seems to repeat what is already said on L193.

rossberg · 2018-02-27T10:30:07Z

proposals/Level-1.md

-`else` instruction.  The scope of the if_except block is from the `if_except`
-instruction to the corresponding `end` instruction.
+The `if_except` block begins with an `if_except` instruction, and
+has two instruction blocks, defined by the `then` and `else` instructions


There isn't really a then instruction.

Can't we add one, to be symmetric with if and else instruction pair?

rossberg · 2018-02-27T10:30:34Z

proposals/Level-1.md

+has two instruction blocks, defined by the `then` and `else` instructions
+like that of an `if` block.
+
+The `if_except` instruction queries of the exception on top of the stack, and


rossberg · 2018-02-27T10:33:25Z

proposals/Level-1.md

-exception index defined in each module.
+For event indices imported/exported, unique event tags are created for each
+unique name imported/exported, and are aliased to the corresponding event index
+defined in each module.

 ## Changes to the binary model


model -> format

rossberg · 2018-02-27T10:34:15Z

proposals/Level-1.md

 ### Data Types

 #### except_ref

-An exception reference points to an exception value. The size
-is fixed, but unknown in WebAssembly (the host defines the size in bytes).
+An exception reference points to an exception. The size is defined by


See earlier comment. I would drop any reference to size, given that it is not observable in any way.

sunfishcode · 2018-02-27T14:10:23Z

In some places (example), this feature is called "zero-cost exceptions", referring to implementation strategies in which non-throwing code is optimized, at the expense of making throwing slow. This is useful for languages like Rust and C++.

Is this proposal still intending to enable zero cost exceptions for WebAssembly?

I'm aware that this is a performance consideration, rather than a semantic consideration.

eholk · 2018-02-27T21:20:26Z

@sunfishcode - While we want to support many languages, I think the primary goal with this proposal is still to make sure C++ is well-supported. I agree that code that does not use throw or try/catch should not take a performance penalty just because the VM supports those exceptions.

Do you have concerns that this proposal will be hard to implement without imposing a pervasive cost on all code?

sunfishcode · 2018-02-27T21:55:19Z

@eholk The term "zero cost" comes from the fact that in typical "zero cost" implementations, entering a try block does not involve executing any code. The main point is that even code that does use try/catch frequently should not take a (significant) performance penalty, in a "zero cost" system.

Unifying exception handling with yield/resume seems counter to the assumptions of a "zero cost" model, because the whole point of a generator, for example, is to yield, often many times. It'd help me to understand this whole proposal if such considerations were documented.

aheejin

Mostly typo fixes

aheejin · 2018-03-01T10:57:02Z

proposals/Level-1.md

-be garbage collected.
+Lastly, exception lifetimes may be maintained by the embedder, so that it can
+collect and reuse the memory used by exceptions. This implies that an embedder
+needs know where exceptions are stored, so that it can determine when an


aheejin · 2018-03-01T10:57:10Z

proposals/Level-1.md

-This also implies that the host VM must provide a garbage collector for
-exceptions.  For host VMs that have garbage collection (such as JavaScript),
+This also implies that that embedders must provide a garbage collector for
+exceptions.  For ebedders that have garbage collection (such as JavaScript),


aheejin · 2018-03-01T11:14:22Z

proposals/Level-1.md

+In general, an event handler allows one to process an event generated by a block
+of code. Events suspend the current execution and look for a corresponding event
+handler. If found, the corresponding event handler is run.  Some event handlers
+my send values back to the suspended instruction, allowing the originating code


aheejin · 2018-03-01T11:16:14Z

proposals/Level-1.md

-event type.
+Each event has an `attribute` and a `type`. Currently, the attribute can only
+specify that the event is an exception. In the future, additional attribute
+values may be added when other events are added to WebAssemble.


WebAssembly

aheejin · 2018-03-01T11:51:51Z

proposals/Level-1.md

+In the first form, the instructions between the `if_except` and 'end' define the
+`then block`. In the second form, the instructions between the `if_except` and
+`else` define the `then block`, while the instructions between the `else` and
+the `end define the `else block`.


missing ` after end

aheejin · 2018-03-01T11:53:03Z

proposals/Level-1.md

+The conditional query of an exception checks the exception tag of exception on
+top of the stack. It succeeds only if the exception index of the instruction
+matches the corresponding exception tag. Once the query completes, the exception
+is poppod off the stack.


aheejin · 2018-03-01T11:58:35Z

proposals/Level-1.md

+function calls until a corresponding, enclosing try block is found. It may also
+associate a stack trace that can be used to report uncaught exceptions. However,
+the details of this is left to the embedder, and WebAssembly does not have
+(direct) access to the stack trace.


I thought the stack trace meant the call stack trace for debugging, but this says the operand stack traces. Are we not gonna have the call stack traces?

The previous version implied that we might add two-phase unwinding in the future. Is there any reason it was deleted?

1 - The stack trace is intended to be a call stack trace, and my read still states this.

We may have two phase (for debugging), but we never stated that it would be mandatory. Dropped because that is an implementation detail and not a requirement.

For what it's worth, stack traces are also an implementation detail since there is no way to access them from Wasm.

Removed the end of the last sentence (on direct access), since it is optional of the implementation.

aheejin · 2018-03-01T12:02:13Z

proposals/Level-1.md

-`else` instruction.  The scope of the if_except block is from the `if_except`
-instruction to the corresponding `end` instruction.
+The `if_except` block begins with an `if_except` instruction, and
+has two instruction blocks, defined by the `then` and `else` instructions


Can't we add one, to be symmetric with if and else instruction pair?

aheejin · 2018-03-01T12:10:08Z

proposals/Level-1.md


+| Field | Type | Description |
+|-------|------|-------------|
+| `index` | `varuitn32` | the index into the corresponding event index space |


aheejin · 2018-03-01T12:14:34Z

Can we add the syntactic sugar then to if_except/else/end as well, to be symmetric with the if/else instruction pair?

aardappel · 2018-03-05T18:05:05Z

@sunfishcode : I voiced some similar concerns here: #42

The paper @rossberg linked https://www.microsoft.com/en-us/research/publication/implementing-algebraic-effects-c/ is very interesting because it has some actual timings you can expect from such resumable exceptions, which initially look pretty bad (compared to an implementation specialized purely for, say, generators), but it also shows a transformation that in a common case can avoid a stack-swap all-together, which would result in a very fast generator.

I agree that it seems that exceptions and generators would have opposite requirements of what path should be fast. I am not sure if the transform mentioned in the paper can be applied commonly enough to bridge that gap.

KarlSchimpf

Fixed misspellings.

KarlSchimpf · 2018-03-07T17:08:20Z

proposals/Level-1.md

-be garbage collected.
+Lastly, exception lifetimes may be maintained by the embedder, so that it can
+collect and reuse the memory used by exceptions. This implies that an embedder
+needs know where exceptions are stored, so that it can determine when an


KarlSchimpf · 2018-03-07T17:09:03Z

proposals/Level-1.md

-This also implies that the host VM must provide a garbage collector for
-exceptions.  For host VMs that have garbage collection (such as JavaScript),
+This also implies that that embedders must provide a garbage collector for
+exceptions.  For ebedders that have garbage collection (such as JavaScript),


KarlSchimpf · 2018-03-07T17:09:25Z

proposals/Level-1.md

+In general, an event handler allows one to process an event generated by a block
+of code. Events suspend the current execution and look for a corresponding event
+handler. If found, the corresponding event handler is run.  Some event handlers
+my send values back to the suspended instruction, allowing the originating code


KarlSchimpf · 2018-03-07T17:10:02Z

proposals/Level-1.md

-event type.
+Each event has an `attribute` and a `type`. Currently, the attribute can only
+specify that the event is an exception. In the future, additional attribute
+values may be added when other events are added to WebAssemble.


KarlSchimpf · 2018-03-07T17:10:37Z

proposals/Level-1.md

+In the first form, the instructions between the `if_except` and 'end' define the
+`then block`. In the second form, the instructions between the `if_except` and
+`else` define the `then block`, while the instructions between the `else` and
+the `end define the `else block`.


KarlSchimpf · 2018-03-07T17:10:59Z

proposals/Level-1.md

+The conditional query of an exception checks the exception tag of exception on
+top of the stack. It succeeds only if the exception index of the instruction
+matches the corresponding exception tag. Once the query completes, the exception
+is poppod off the stack.


KarlSchimpf · 2018-03-07T17:14:59Z

proposals/Level-1.md

+function calls until a corresponding, enclosing try block is found. It may also
+associate a stack trace that can be used to report uncaught exceptions. However,
+the details of this is left to the embedder, and WebAssembly does not have
+(direct) access to the stack trace.


1 - The stack trace is intended to be a call stack trace, and my read still states this.

We may have two phase (for debugging), but we never stated that it would be mandatory. Dropped because that is an implementation detail and not a requirement.

KarlSchimpf · 2018-03-07T17:15:23Z

proposals/Level-1.md


+| Field | Type | Description |
+|-------|------|-------------|
+| `index` | `varuitn32` | the index into the corresponding event index space |


eholk · 2018-03-07T18:59:23Z

@sunfishcode @aardappel - @lukewagner voices similar concerns about the cost of throwing and catching exceptions in #19. Why don't we consolidate this discussion there and update the proposal as needed based on the results of the discussion?

eholk

lgtm modulo nits

eholk · 2018-03-07T22:22:40Z

proposals/Level-1.md

@@ -1,4 +1,4 @@
-# Level 1 exception handling
+ Level 1 exception handling


nit: I'd leave the # so this is a heading.

eholk · 2018-03-07T22:54:25Z

proposals/Level-1.md

+In the first form, the instructions between the `if_except` and 'end' define the
+`then block`. In the second form, the instructions between the `if_except` and
+`else` define the `then block`, while the instructions between the `else` and
+the `end` define the `else block`.


@sunfishcode pointed out that this optional else block complicates decoding. We should consider making this not optional (#54). This is an issue for another PR though.

eholk · 2018-03-07T22:55:21Z

proposals/Level-1.md

-found, it could terminate the thread at the point of the throw. This would
-allow better debugging capability, since the corresponding call stack is still
-there to query.
+When an exception is thrown, the runtime will pop the operand stack across


It's probably okay to be a little imprecise and just say "pop the stack across function calls" rather than specifying it's the operand stack.

What I meant by "why only the operand stack traces and not call stack traces" here is this too.

Removed "operand".

eholk · 2018-03-07T22:57:13Z

proposals/Level-1.md


-##### Exception section
+##### event section


nit: capitalize "Event."

* Add event handling * Clean up text * Clean up more * Fix order of arguments for if_except * Clean up description of event index/tag * Fix mispellings * Fix more nits

KarlSchimpf added 2 commits February 26, 2018 14:47

Add event handling

4c50654

Merge branch 'fix' of https://github.com/KarlSchimpf/exception-handling…

b522bd8

… into KarlSchimpf-fix

rossberg reviewed Feb 27, 2018

View reviewed changes

KarlSchimpf added 4 commits February 28, 2018 10:09

Clean up text

186564c

Clean up more

74dc728

Fix order of arguments for if_except

2f76abe

Clean up description of event index/tag

b63ba57

aheejin reviewed Mar 1, 2018

View reviewed changes

Fix mispellings

82ec216

KarlSchimpf commented Mar 7, 2018

View reviewed changes

eholk mentioned this pull request Mar 7, 2018

Should producers/consumers assume throwing is "rare" and, if so, can the spec note this? #19

Open

eholk approved these changes Mar 7, 2018

View reviewed changes

Fix more nits

61d06cc

KarlSchimpf merged commit b228f3a into WebAssembly:master Mar 8, 2018

KarlSchimpf deleted the KarlSchimpf-fix branch March 8, 2018 20:42

eholk mentioned this pull request Mar 12, 2018

Should if_except pop the exception off the stack? #44

Closed

aheejin mentioned this pull request Jul 15, 2020

Two-phase unwinding and its implications #123

Closed

		@@ -1,4 +1,4 @@
		# Level 1 exception handling
		Level 1 exception handling

Generalize exceptions to events #49

Generalize exceptions to events #49

Uh oh!

Conversation

KarlSchimpf commented Feb 26, 2018

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

sunfishcode commented Feb 27, 2018 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

eholk commented Feb 27, 2018

Uh oh!

sunfishcode commented Feb 27, 2018

Uh oh!

aheejin left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

aheejin commented Mar 1, 2018

Uh oh!

aardappel commented Mar 5, 2018

Uh oh!

KarlSchimpf left a comment

Choose a reason for hiding this comment

sunfishcode commented Feb 27, 2018 •

edited

Loading