Automatic `INITIAL_MEMORY` for statically large modules

[SingleAccretion]

Right now the default value of INITIAL_MEMORY is 16MB, which sets a hard limit on the amount of static data in a module - the linker will error out if the amount is insufficient. To work around this, you need to be able to calculate the number beforehand, e. g. the official .NET SDK guesstimates by doing something to the effect of going over all of the inputs and summing their size.

This all seems rather self-inflicted. The linker already knows how much memory will it need, and indeed, if you don't pass --initial-memory, it will already "do the right thing".

The question is, can this automatic behavior be supported by Emscripten natively?

Note: this is all assuming memory growth is allowed, of course.

[sbc100]

The problem I suppose is the INITIAL_MEMORY really means + stack + static data + heap, but what you really want is a way to specify just the heap size.

I guess for most folks this isn't a huge issue since most programs don't tend to have a lot of static data. 16mb of static data is fairly unusual I think.

Would -sINITIAL_HEAP help here? We could have it default to 16mb too, but that would be 16mb on top of the static data. Right now we don't have a wasm-ld flag for this so we would need to add a new one.

[SingleAccretion]

My initial thought was a way to simply not pass anything (effectively, initial heap size of zero). Allowing one to configure the initial heap size on top of that would be an optimization - how significant is it?

I guess for most folks this isn't a huge issue since most programs don't tend to have a lot of static data. 16mb of static data is fairly unusual I think.

That's true, the motivation here is removing the (unnecessary) complexity from the toolchain.

[sbc100]

My initial thought was a way to simply not pass anything (effectively, initial heap size of zero). Allowing one to configure the initial heap size on top of that would be an optimization - how significant is it?

Sadly this won't work without some other changes since we default to a non-growable memory. Most programs would not work with a heap size of zero.

I guess for most folks this isn't a huge issue since most programs don't tend to have a lot of static data. 16mb of static data is fairly unusual I think.

That's true, the motivation here is removing the (unnecessary) complexity from the toolchain.

Are you referring to existing complexity in emscripten? Or in the .NET toolchain?

[sbc100]

Ah, I assume you are referring to the referring guesstimate code that you linked to above. I agree that should really not be necessary.

[SingleAccretion]

Sadly this won't work without some other changes since we default to a non-growable memory. Most programs would not work with a heap size of zero.

Would making this only supported with -sALLOW_MEMORY_GROWTH=1 work (it was my intention)? I can implement the larger feature too, it just seemed to me that -sALLOW_MEMORY_GROWTH=0 is not really a used-in-production sort of setting (is that wrong?).

[sbc100]

Sadly this won't work without some other changes since we default to a non-growable memory. Most programs would not work with a heap size of zero.

Would making this only supported with -sALLOW_MEMORY_GROWTH=1 work (it was my intention)? I can implement the larger feature too, it just seemed to me that -sALLOW_MEMORY_GROWTH=0 is not really a used-in-production sort of setting (is that wrong?).

Sure, I think making this work for -sALLOW_MEMORY_GROWTH=1 is conceivable.

But the default setting is -sALLOW_MEMORY_GROWTH=0 and I assume that what most folks use. Allowing memory growth does have some downsides and I imagine changing the default to -sALLOW_MEMORY_GROWTH=1 could have some negative repercussions.

But defaulting to simply not passing --initial-memory in the case when the memory is growable seems like it could.. assuming the default for max memory is high enough (we still need to pass that default).

[SingleAccretion]

I will work on the full INITIAL_HEAP feature then. What is the usual delay between adding an LLVM feature and being able to consume it in Emscripten (weeks/months)?

[sbc100]

Emscripten uses tip of tree llvm. We integrate changes right away.

[SingleAccretion]

@sbc100 I've drawn up the design sketch for the Emscripten side of this work:

First-class Emscripten setting ("-sINITIAL_HEAP").

Defaults:
  Old: INITIAL_MEMORY=16MB
  New: INITIAL_MEMORY=<unspecified>
       INITIAL_HEAP=16MB; backwards compatibility: cannot be less than previously set

Interactions:
 -- With MAXIMUM_MEMORY
    -- Default: cannot be larger than (MAXIMUM_MEMORY - (stack size + size of static data)).
       -- We don't the size of static data, hence to preserve compatibility, we cannot use
          INITIAL_HEAP when MAXIMUM_MEMORY is specified.
    -- Explicit: defer validation to wasm-ld.
 -- With INITIAL_MEMORY
    -- Default: should not be passed.
    -- Explicit: defer validation to wasm-ld.
       -- Alternative: make it an error?

Does it look good to you?

As INITIAL_MEMORY is already defaulted right now, it seems hard to not expose this as a first-class setting - that would require digging through user-supplied linker args (-Wl) for --initial-heap presence, and omitting --initial-memory if it is present.

[sbc100]

This sounds good to me.

I think we could probably also deprecate INITIAL_MEMORY at some point since it seems strictly better to use STACK_SIZE and INITIAL_HEAP.

[sbc100]

The llvm change should now be available in emscripten, of you would like a set a PR here.