List and describe post-MVP features in more detail #114
Conversation
rossberg
changed the title
Co-authored-by: Thomas Lively <[email protected]>
proposals/gc/Post-MVP.md
Outdated
| ## "Butterfly Objects" | ||
|
|
||
| One common suggestion is to merge structs and arrays into a single construct with both struct-like fields and a array-like elements. |
There was a problem hiding this comment.
These are not butterfly objects. They are arrays with headers.
There was a problem hiding this comment.
Agreed that a butterfly object, by my understanding, extends dynamically in "both directions" which is not what is described below. That being said, just as the current verbiage for flexible aggregates captures "arrays with headers" by allowing flexible aggregates at the end of a struct, you could also imagine allowing flexible aggregates at the beginning of a struct which, with proper care in the subtyping rules, would allow a butterfly implementation. In fact, it would generalize pure butterfly objects by allowing a fixed set of statically-typed fields to be stored in the "middle" of the butterfly object.
There was a problem hiding this comment.
Good point, renamed to "arrays with fields".
proposals/gc/Post-MVP.md
Outdated
| With the extension sketched below, it is possible, for example, to represent the equivalent of ["butterfly objects"](#butterfly-objects), by nesting a dynamically-sized array at the end of the struct. | ||
| For example: | ||
| ``` | ||
| (type $Array (array i32)) | ||
| (type $Butterfly (struct f32 i64 (type $Array)) | ||
| ``` |
There was a problem hiding this comment.
This is not a butterfly object. A butterfly has two arrays that spread out from the "center" of the object (one at positive offsets and the other at negative offsets).
|
|
||
| Imported types are essentially parameters to the module. | ||
| As such, they are entirely abstract, as far as compile-time validation is concerned. | ||
| The only operations possible with them are those that do not require knowledge of their actual definition or size: primarily, passing and storing references to such types. |
There was a problem hiding this comment.
This should mention casting with rtts and with call_indirect.
| - or `ft = (type $t')` and `$l : [(inref $t')]` | ||
| - i.e., if the field type is a scalar, pass its value to the label, otherwise an interior reference |
There was a problem hiding this comment.
Clever use of interior references!
proposals/gc/Post-MVP.md
Outdated
| ## "Butterfly Objects" | ||
|
|
||
| One common suggestion is to merge structs and arrays into a single construct with both struct-like fields and a array-like elements. |
There was a problem hiding this comment.
Agreed that a butterfly object, by my understanding, extends dynamically in "both directions" which is not what is described below. That being said, just as the current verbiage for flexible aggregates captures "arrays with headers" by allowing flexible aggregates at the end of a struct, you could also imagine allowing flexible aggregates at the beginning of a struct which, with proper care in the subtyping rules, would allow a butterfly implementation. In fact, it would generalize pure butterfly objects by allowing a fixed set of statically-typed fields to be stored in the "middle" of the butterfly object.
| @@ -0,0 +1,563 @@ | |||
| # GC Post-v1 Extensions | |||
|
|
|||
| This document discusses various extensions which seem desirable for comprehensive support of GC types, but are intentionally left out of the [MVP](MVP.md), in order to keep its scope manageable. | |||
There was a problem hiding this comment.
Perhaps add a sentence to the effect of: "Over the course of implementing and validating the MVP, it is possible that features in this list may be promoted to the MVP if experience shows that MVP performance would not otherwise be viable." ?
proposals/gc/Post-MVP.md
Outdated
|
|
||
| Allocation: | ||
|
|
||
| * Allocation instructions like `struct.new` expect initialiser operands for nested aggregates: each individual field for a nested struct, and one initialiser for a nested array (which may itself be a list of initialisers, if the array's element type is a again a struct). Details TBD. |
There was a problem hiding this comment.
| * Allocation instructions like `struct.new` expect initialiser operands for nested aggregates: each individual field for a nested struct, and one initialiser for a nested array (which may itself be a list of initialisers, if the array's element type is a again a struct). Details TBD. | |
| * Allocation instructions like `struct.new` expect initialiser operands for nested aggregates: each individual field for a nested struct, and one initialiser for a nested array (which may itself be a list of initialisers, if the array's element type is again a struct). Details TBD. |
proposals/gc/Post-MVP.md
Outdated
|
|
||
| An engine should be able to optimise away intermediate interior pointers very easily. | ||
|
|
||
| * TBD: As sketched here, interior references can only point ot nested aggregates. Should there also be interior references to plain fields? |
There was a problem hiding this comment.
| * TBD: As sketched here, interior references can only point ot nested aggregates. Should there also be interior references to plain fields? | |
| * TBD: As sketched here, interior references can only point to nested aggregates. Should there also be interior references to plain fields? |
proposals/gc/Post-MVP.md
Outdated
| Unfortunately, hardware differs widely in how many tagging bits a pointer can conveniently support, and different VMs might have additional constraints on how many of these bits they can make available to user code. | ||
| In order to provide tagging in a way that is portable but maximally efficient on any given hardware and engine, a somewhat higher level of abstraction is useful. | ||
|
|
||
| Such a more high-level solution would be to support a form of _variant types_ (a.k.a. disjoint unions or sum types) in the type system. |
There was a problem hiding this comment.
| Such a more high-level solution would be to support a form of _variant types_ (a.k.a. disjoint unions or sum types) in the type system. | |
| Such a higher-level solution would be to support a form of _variant types_ (a.k.a. disjoint unions or sum types) in the type system. |
Incorporate active/passive segments into instantiation. While doing so, drop the notion of segment types as well as initelem/initdata administrative instructions and express the latter in terms of table.init and memory.init instructions. Adjust interpreter accordingly.
More fixes and tests around element segments
A somewhat more complete and detailed write-up of post-MVP features, and rationale why they are not included in the proposed MVP. It is intended to clarify some reoccurring questions and suggestions about the proposal. Probably not a comprehensive list yet, but making progress. :)