Remove static allocation from JS compiler #11773
Comments
|
I've tried to do this in the past of found some places where it was hard/impossible for me to replace |
|
Removing |
This is a followup on #11437 which added this API. Sadly today the linker doesn't know the final memory layout so until we fix #11773 this extra `init` function is needed. The alternative, which is to modify binaryen and emscripten to inject the stack end value post-link is IMHO way to much complexity to justify the convenience of not having the call this init function. Once we fix #11773 the init function can become uneeded/no-op.
|
Out of curiosity, Can this affect Asyncify? |
|
@sbc100 sounds good - we should probably wait for fastcomp removal first though to avoid extra complexity and work. I imagine this would require moving a bunch of things from JS into C or .s files, which should be a good improvement for them anyhow. @gerald-dotcom I don't think asyncify does static allocations (it does dynamic allocations, but those are fine) |
This is a followup on #11437 which added this API. Sadly today the linker doesn't know the final memory layout so until we fix #11773 this extra `init` function is needed. The alternative, which is to modify binaryen and emscripten to inject the stack end value post-link is IMHO way to much complexity to justify the convenience of not having the call this init function. Once we fix #11773 the init function can become uneeded/no-op.
This is a followup on #11437 which added this API. Sadly today the linker doesn't know the final memory layout so until we fix #11773 this extra `init` function is needed. The alternative, which is to modify binaryen and emscripten to inject the stack end value post-link is IMHO way to much complexity to justify the convenience of not having the call this init function. Once we fix #11773 the init function can become uneeded/no-op.
This is a followup on #11437 which added this API. Sadly today the linker doesn't know the final memory layout so until we fix #11773 this extra `init` function is needed. The alternative, which is to modify binaryen and emscripten to inject the stack end value post-link is IMHO way to much complexity to justify the convenience of not having the call this init function. Once we fix #11773 the init function can become uneeded/no-op.
This is a followup on #11437 which added this API. Sadly today the linker doesn't know the final memory layout so until we fix #11773 this extra `init` function is needed. The alternative, which is to modify binaryen and emscripten to inject the stack end value post-link is IMHO way to much complexity to justify the convenience of not having the call this init function. Once we fix #11773 the init function can become uneeded/no-op.
This is a followup on #11437 which added this API. Sadly today the linker doesn't know the final memory layout so until we fix #11773 this extra `init` function is needed. The alternative, which is to modify binaryen and emscripten to inject the stack end value post-link is IMHO way to much complexity to justify the convenience of not having the call this init function. Once we fix #11773 the init function can become unneeded/no-op.
|
Was this intentionally closed? I think that PR might have closed the wrong issue @sbc100 |
|
I think that PR referenced this issue, but I didn't mean to close it. |
|
This issue has been automatically marked as stale because there has been no activity in the past year. It will be closed automatically if no further activity occurs in the next 30 days. Feel free to re-open at any time if this issue is still relevant. |
We have a function in the JS compiler called
makeStaticAllocthat can allocate static data after the linker has run.This can be a useful feature but it comes with a lot of extra code complexity and downsides.
The biggest problem is that the linker traditionally assumes that it controls data layout, and knows the start and end of the data, stack, and heap regions. With emscripten we have hacks to retroactively update the internal
__stack_pointerand inject the stack limit in some cases. It also confuses code that relies on linker-generated symbols such asedata.The second problem is that any such allocations are not available in standalone mode.
The more of these allocations we can push into native code the fewer JS hacks we will need and the fewer magic binaryen step will be needed. Giving the linker visibility of all these symbols also allows gives it a better chance to do DCE and results in a wasm binary with fewer imports.
For example
emscripten_stack_get_baseandemscripten_stack_get_endcurrently call out to JS which is bad for performance and code size and portability.The text was updated successfully, but these errors were encountered: