Update proposal to include {mem,table}.drop #85
Conversation
|
See #62 (comment). |
| as an operand to `mem.init` or `table.init`. | ||
|
|
||
| Segments (either active or inactive) can also be discarded by using the | ||
| following new instructions: |
There was a problem hiding this comment.
Gosh, I'm not sure if it's a good idea to be able to drop active memories. Suppose you can, and do. Then you instantiate the module again. What happens then? A trap? (That would be the interpretation of the prose further down.)
There was a problem hiding this comment.
Yeah, I wasn't sure about this one. I was thinking it would be a nice optimization to be able to discard to active segments (say, if you know that there will never be another instance), but perhaps we should be more conservative.
There was a problem hiding this comment.
I'd err on the side of conservative.
|
|
||
| Note that it is allowed to use `init_memory` on the same data segment more than | ||
| Note that it is allowed to use `mem.init` on the same data segment more than | ||
| once, or with an active data segment. |
There was a problem hiding this comment.
I think it's a mistake to allow mem.init to be used with an active data segment. The current contract is that the active data segment may be dropped by the implementation once the Module object becomes GC-able. This makes mem.init sensitive to GC timing, because it'll have to trap if the data segment has been removed.
IMO all the programmatic mem opcodes should only be usable with the inactive data segments.
(I also have decided I dislike the terminology "active" and "inactive", but I've been at a loss to propose something better. Still am, really. But "instantiation-time" vs "run-time" would capture the distinction better.)
There was a problem hiding this comment.
Yes, I think you're right. I'll try to find some time to update before the end of the year... (at home with the family 😄).
|
I've renamed |
|
Landing for now, we can iterate in further PRs. |
No description provided.