Clarifications on "more complex" unchanged instructions

[Liedtke]

We should clarify if the following specifications are desired:

• table.copy can copy between shared and unshared tables (all 4 combinations¹, also for all the other cases below)
• array.copy can copy between shared and unshared arrays
• table.init can initialize shared and unshared tables from shared and unshared element segments
• array.new_elem can construct shared and unshared arrays using shared and unshared element segments
• array.new_data can construct shared and unshared arrays using shared and unshared data segments
• array.init_data and array.init_elem can similarly use a mix of shared and unshared arrays and element / data segments

AFAICT that's what this proposal is currently defining, I can say for sure that the V8 implementation does not support most of these cases (some of the bulk instructions might not work at all for shared types in the current POC.)

Footnotes

1. Inside an unshared function ↩

[tlively]

If it weren't for memory model concerns, I would expect that all these should work just fine. But @conrad-watt, do you have an opinion here?

[conrad-watt]

These all seem fine!

[Liedtke]

If it weren't for memory model concerns, I would expect that all these should work just fine.

Maybe I should've clarified my question: While these configurations don't cause issues e.g. in terms of shared->unshared edges, the question is if these are desirable to have / if there is any use case for them.

I don't think I fully understood how sharing Wasm instances will work.
Is it possible to share an instance (post-message to another Worker one the Web) that contains any unshared element segments, globals, ...?

I assume the answer is "No"?
As there seems to be consensus that "shared-everything" doesn't only mean that "everything is shareable" but that it also realistically means "if you share one thing, you'll need to share everything" because tool-chains and source languages can't really handle that otherwise.
That would mean that a module using shared globals, element segments, ... would never define an unshared global, ..., as that would prevent the instance from being shared.
So there wouldn't be any point of supporting these mixed operations.

If the answer is "Yes":
If we have shared, unshared and thread_local globals of shared element types, what is the difference between an unshared global and a thread_local global?
Will there be a way to create multiple instantiations of the unshared part that share the same shared part but are still located in the same thread? How will the instantiation be invoked of the unshared instance part in JS user-space?

[tlively]

I don't think I fully understood how sharing Wasm instances will work.
Is it possible to share an instance (post-message to another Worker one the Web) that contains any unshared element segments, globals, ...?

No. We'll either be postmessaging the individual shared exports or postmessaging some new SharedInstance thing that only encapsulates the shared exports. A normal Instance containing unshared exports would not be postmessageable.

That would mean that a module using shared globals, element segments, ... would never define an unshared global, ..., as that would prevent the instance from being shared.
So there wouldn't be any point of supporting these mixed operations.

There will always be a need to shovel bytes from one place to another! If an app has one module where everything is shared and another that is single-threaded, the modules may still want to pass data to one another. This can always be done via JS, but it would save at least one copy to do a table.copy, array.copy, or memory.copy. I can imagine the mixed-sharedness new and init instructions also being used to reduce memory duplication from element segments even when the initialized or allocated arrays or tables have been optimized (somehow) to not be shared.

[Liedtke]

I can imagine the mixed-sharedness new and init instructions also being used to reduce memory duplication from element segments even when the initialized or allocated arrays or tables have been optimized (somehow) to not be shared.

Converting a shared table to an unshared table is not an optimization (otherwise it wouldn't be an optimization to keep the element-segment shared? If we optimize for memory-usage and a Wasm instance is shared across multiple threads, all memories, globals, ... should be made shared if they store the same data.)

When it comes to Wasm arrays and structs: "Optimizing" parts of a module to be unshared for performance reasons would mean duplicating all parts of the type section that now have an unshared counterpart, similarly, these would become incompatible, so if we had an optimization that made java.lang.ArrayList<java.lang.String> unshared in some cases, any function on that ArrayList would need to be duplicated in an unshared variant. If we further optimize it to also make the java.lang.String unshared in those cases where we can, we'd also need to add another duplication as the unshared variant can only hold unshared string or shared string but not both. All these optimizations would therefore have significant regressions on both wire-byte-size as well as memory consumption in the engine for the duplicated jit-code-instances etc.
I am skeptical if any such optimization would work out on a larger scope.

I don't have strong concerns on any of these extra variants. I am just saying that these "overloads" increase the feature scope of this incredibly large proposal and therefore will affect the timeline for any engine to support a shippable (subset) of this proposal, so it is a trade-off how many of these "probably not needed" features should be included.

[tlively]

Yes, all good points. I'm happy to leave this open and defer any decision making to later when we consider shared tables and segments and things more concretely on the implementation side.