multi-memory

multi-memory copied to clipboard

The overview already covers the fact that many implementations reserve a register for the heap pointer and suggests that this could be reserved for memory 0. This is a good idea, but we might consider taking it a little bit further.

In particular, while we might want to use all sorts of tricks for the primary memory, including a heap base register and large vm reservations to avoid bounds checking on 64-bit systems, we might not wish to pay the cost of using those tricks on secondary memories, or it may be nice to avoid them if possible. On both mobile systems and in other contexts, with large reservations for every memory, it is possible to not run wasm effectively. We've had bugs reported from more restricted operating systems such as OpenBSD and (I suspect) VM-based installations that strongly restrict the virtual memory space for user programs.

At Mozilla we've been tossing around the idea for some time that it may be desirable to designate some memories as "optimized-for-speed" and others as "optimized-for-size", for the lack of better nomenclature. It's possible that we should consider these attributes in the context of multi-memory. An optimized-for-speed memory might get a dedicated register for the heap base, and the VM tricks, while an optimized-for-space memory would get the smallest allocation and probably explicit bounds checking.

The problem with the attributes is the same as with "shared" -- the importer and the exporter have to have matched attributes on each memory at linking time. Yet resource optimization a practical problem worth solving.

(Perhaps instead of optimized-for-speed and optimized-for-size the attributes should be "primary" and "secondary", and there can only be one "primary" per module.)

During the last CG meeting, we discussed whether this is something we need to consider as part of the proposal, or whether it could be a later addition. The discussion was inconclusive.

The argument in favour of doing it now is that it might avoid surprising and/or unfortunate performance regressions, especially when merging modules. The counter argument is that this problem can only come up for programs you cannot even write at all at the moment.

There also was the concern that we'd need a more general design for performance hints in general before adding them ad-hoc. One preference was doing that in a separate section, since it is not semantically relevant. The concern there was that some of the information might have to be in the types, in order to track it correctly in the presence of future extensions like first-class memories. Neither approach is incompatible with adding it as a future extension over the current proposal, however.

@lars-t-hansen, is that an accurate summary of the discussion? Do you think that optimisation hints have to be integrated into the current proposal or is it sufficient to consider them as a separate extension?

@rossberg, I think that's a very fair summary.

I think some of the "hints" will turn out to be semantic at least in the sense of affecting linking and the idea of a "hints section" is glossing over too much.

Just want to mention another aspect that Luke brought up, which is the possibility of having a configurable page size, so as to enable very small memories. This too would have semantic meaning.

I'm not going to push hard to include hints or memory attributes in the initial spec, but I will note that on some operating systems such attributes may be important determinants of whether wasm content runs at all, and in other cases of whether it runs well. In particular, the primary/secondary memory distinction can be important.

Firefox bug with some performance assessments from when we tried to get rid of our pinned heap base register: https://bugzilla.mozilla.org/show_bug.cgi?id=1342121. Modest performance losses in the optimized code, larger in the baseline code.