Skip to content

[AUDIO_WORKLET] Add support for MEMORY64 with 2GB and 4GB heap #24732

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Draft
wants to merge 8 commits into
base: main
Choose a base branch
from

Conversation

cwoffenden
Copy link
Contributor

@cwoffenden cwoffenden commented Jul 17, 2025

This pulls the changes out of #23508 to add just the MEMORY64 support.

The already merged interactive tests (from #23659) can be run with:

test/runner.py interactive_2gb.test_audio_worklet_params_mixing
test/runner.py interactive64_4gb.test_audio_worklet_params_mixing

The browser tests with wasm64 have been re-enabled.

Note: the intention is to add the performance improvements (from last October) once this is merged (which are still relevant and produce the same improvements).

Will need a once-over when #24734 lands.

@cwoffenden
Copy link
Contributor Author

cwoffenden commented Jul 21, 2025

These failing size related tests are unrelated to the changes:

test_minimal_runtime_code_size_hello_webgl_wasm2js
test_minimal_runtime_code_size_hello_webgl_wasm
test_minimal_runtime_code_size_hello_webgl2_wasm2js
test_minimal_runtime_code_size_hello_webgl2_wasm

They don't fail for me with Emscripten 4.0.12 built from sdk-main-64bit.

The failing test_codesize_hello_dylink_all is fixed in #24742.

@sbc100
Copy link
Collaborator

sbc100 commented Jul 21, 2025

These failing size related tests are unrelated to the changes:

test_minimal_runtime_code_size_hello_webgl_wasm2js
test_minimal_runtime_code_size_hello_webgl_wasm
test_minimal_runtime_code_size_hello_webgl2_wasm2js
test_minimal_runtime_code_size_hello_webgl2_wasm

They don't fail for me with Emscripten 4.0.12 built from sdk-main-64bit.

The failing test_codesize_hello_dylink_all is fixed in #24742.

To successfully rebaseline codesize tests on main you need to first run emsdk install tot to ensure you have the very latest llvm + binaryen running.

For pre-existing codesize changes we have a bot that automatically updates them.. I'll trigger it now so that main is up-to-date.

@cwoffenden
Copy link
Contributor Author

To successfully rebaseline codesize tests on main you need to first run emsdk install tot to ensure you have the very latest llvm + binaryen running.

What's the difference between tot and sdk-main-64bit? I've always used sdk-main-64bit because I can quickly switch between Emscripten's origin (main in the repo) and my own remote's branch.

@sbc100
Copy link
Collaborator

sbc100 commented Jul 21, 2025

To successfully rebaseline codesize tests on main you need to first run emsdk install tot to ensure you have the very latest llvm + binaryen running.

What's the difference between tot and sdk-main-64bit? I've always used sdk-main-64bit because I can quickly switch between Emscripten's origin (main in the repo) and my own remote's branch.

tot is like 4.0.10 in that installs pre-built binaries from our build servers (https://ci.chromium.org/p/emscripten-releases/g/main/console)

sdk-main-64bit is not used my many folks, it builds everything from source (which most ppl don't want to do). I think it updates the main branch each time its run but I don't remember for sure.

The tot binaries are what the emscripten CI tests run against.

The easiest way to use any emscripten checkout without emsdk binaries is to do set EM_CONFIG=/path/to/emsdk/.emscripten. Then you can do a git checkout of emscripten and run ./emcc ... and the emscripten checkout will use llvm and binaryen binaries from emsdk. See https://emscripten.org/docs/tools_reference/emsdk.html#how-do-i-use-my-own-emscripten-fork-with-the-sdk

@cwoffenden
Copy link
Contributor Author

sdk-main-64bit is not used my many folks, it builds everything from source (which most ppl don't want to do).

I think it’s a throwback from LLVM fixes we were doing, and it’s stuck. I’ll switch to tot.

@cwoffenden
Copy link
Contributor Author

cwoffenden commented Jul 22, 2025

Unrelated fails seem Chrome related, same as #24750 for example.

(Re-run and passed)

@cwoffenden
Copy link
Contributor Author

@sbc100 Any chance of a review of this? It's a shorter replacement for the earlier one, discussed here way back when:

#23508 (comment)

var audioParams = [],
processorName = UTF8ToString({{{ makeGetValue('options', C_STRUCTS.WebAudioWorkletProcessorCreateOptions.name, '*') }}}),
numAudioParams = {{{ makeGetValue('options', C_STRUCTS.WebAudioWorkletProcessorCreateOptions.numAudioParams, 'i32') }}},
audioParamDescriptors = {{{ makeGetValue('options', C_STRUCTS.WebAudioWorkletProcessorCreateOptions.audioParamDescriptors, '*') }}},
i = 0;
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can we convert to one-line-per-declaration here? I think it would help make this more readable, and should not effect minified code size.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Happily - I just followed the original style.

this.callback = getWasmTableEntry(opts.callback);
this.userData = opts.userData;
this.callback = getWasmTableEntry({{{ toIndexType("opts.callback") }}});
this.userData = {{{ toIndexType("opts.userData") }}};
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This second line doesn't look quite right to me.

userData I assume is a pointer, which means it should be Number and not a bigint (it should be converted to a Number when it first arrived on the JS side).

If it needs to be converted back to a pointer (i64) when this.callback then you should be using to64 at the callback call side, and not here.

toIndexType should only be used for places where you are direclty accessing the table, or the memory bounds.

Can you test with -sMEMORY64=2 as well perhaps to catch these cases where there is difference between to64 and toIndexType?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, it's to convert it back to a pointer. It's constant, so I removed the need to keep doing the conversion.

I can test with -sMEMORY64=2 and put the conversions near the call.

@sbc100
Copy link
Collaborator

sbc100 commented Jul 30, 2025

(Probably not worth adding a -sMEMORY64=2 mode actually.. although maybe test locally with it?

sbc100 added a commit to sbc100/emscripten that referenced this pull request Jul 30, 2025
The convention for JS library code is to use var for better
minification.

The use of `void 0` instead of `undefined` I believe is a minor code
size optimization, but its somewhat obscure and (as you can see from the
fact that the code expectations didn't change) it an optimization that
is already performed on the generated code anyway.

Split out from emscripten-core#24732
sbc100 added a commit to sbc100/emscripten that referenced this pull request Jul 30, 2025
The convention for JS library code is to use var for better
minification.

The use of `void 0` instead of `undefined` I believe is a minor code
size optimization, but its somewhat obscure and (as you can see from the
fact that the code expectations didn't change) it an optimization that
is already performed on the generated code anyway.

Split out from emscripten-core#24732
sbc100 added a commit to sbc100/emscripten that referenced this pull request Jul 30, 2025
The convention for JS library code is to use var for better
minification.

The use of `void 0` instead of `undefined` I believe is a minor code
size optimization, but its somewhat obscure and (as you can see from the
fact that the code expectations didn't change) it an optimization that
is already performed on the generated code anyway.

Split out from emscripten-core#24732
sbc100 added a commit to sbc100/emscripten that referenced this pull request Jul 30, 2025
The convention for JS library code is to use var for better
minification.

The use of `void 0` instead of `undefined` I believe is a minor code
size optimization, but its somewhat obscure and (as you can see from the
fact that the code expectations didn't change) it an optimization that
is already performed on the generated code anyway.

Split out from emscripten-core#24732
sbc100 added a commit to sbc100/emscripten that referenced this pull request Jul 30, 2025
The convention for JS library code is to use var for better
minification.

The use of `void 0` instead of `undefined` I believe is a minor code
size optimization, but its somewhat obscure and (as you can see from the
fact that the code expectations didn't change) it an optimization that
is already performed on the generated code anyway.

Split out from emscripten-core#24732
sbc100 added a commit that referenced this pull request Jul 30, 2025
The convention for JS library code is to use var for better
minification.

The use of `void 0` instead of `undefined` I believe is a minor code
size optimization, but its somewhat obscure and (as you can see from the
fact that the code expectations didn't change) it an optimization that
is already performed on the generated code anyway.

Split out from #24732
@cwoffenden cwoffenden marked this pull request as draft July 31, 2025 20:15
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants