Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add throwing instructions and funcref equality to Post-MVP #340

Merged
merged 2 commits into from
Nov 16, 2022
Merged

Add throwing instructions and funcref equality to Post-MVP #340

Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
5a12e18
Add throwing instructions and funcref equality to Post-MVP
tlively Nov 15, 2022
9a2a63a
mention the EH dependency
tlively Nov 16, 2022
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
16 changes: 16 additions & 0 deletions proposals/gc/Post-MVP.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -21,6 +21,7 @@ See [overview](Overview.md) for addition background.
* [Weak references](#weak-references)
* [Method dispatch](#method-dispatch)
* [Handle nondefaultable fields in `struct.new_default`](#handle-nondefaultable-fields-in-structnew_default)
* [Throwing versions of trapping instructions](#throwing-versions-of-trapping-instructions)

## Bulk Operations

Expand Down Expand Up @@ -773,3 +774,18 @@ The problem could be addressed by extending the type system with features that a
As proposed in #174. The idea is that `struct.new_default` would take values for nondefaultable fields in the struct from the stack. This would be a code size optimization over having to specify every single field with `struct.new` when allocating a struct containing nondefaultable fields.

**Why Post-MVP:** This is a local code size optimization that does not affect expressivity, so getting it into the MVP is not urgent.


## Throwing versions of trapping instructions

Some language implementers have expressed interest in having throwing versions of operations like `struct.get` to simplify the implementation of e.g. Java's `NullPointerException`. It may be worth investigating what the potential code size or performance benefits of these instructions would be. See [#208](https://github.com/WebAssembly/gc/issues/208) for details and previous discussion.

**Why Post-MVP:** Null checks followed by throws are easily expressible in the MVP, so there is no pressing need to add additional instructions for this pattern. Also, throwing instructions would depend on the exception handling proposal, and we would prefer to avoid that dependency in the MVP.


## Equality-comparable funcref

Being able to compare function references for equality would enable more precise polymorphic devirtualization. On the other hand, some polymorphic devirtualization should already be possible by taking advantage of patterns in vtables and letting functions be equality comparable would inhibit function deduplication optimizations. See [#239](https://github.com/WebAssembly/gc/issues/239) for details and previous discussion.

**Why Post-MVP:** The benefits of this change are unknown and would likely be small, so it's not urgent that we get this into the MVP.