Add runtime detection for toResizableBuffer

[sbc100]

Since this is now shipping in the current version of all major browsers
we want to take advantage of it whenever possible.

See the ChangeLog entry and docs for why it still makes sense to keep
the explicit GROWABLE_ARRAYBUFFERS setting around (at least for
now).

As a side effect this change also works around #27084.

[kleisauke]

I am leaving the GROWABLE_ARRAYBUFFERS setting in place for now since
enabling it unconditionally can still save a little on codesize but we
may want to to just remove that at some point.

A nice thing about -sGROWABLE_ARRAYBUFFERS is that it also avoids the emscripten_notify_memory_growth(0) call that would otherwise be triggered each time Wasm memory grows.

emscripten/system/lib/standalone/standalone.c

Lines 138 to 141 in d1fbb02

	#if !defined(EMSCRIPTEN_PURE_WASI)
	// Success, update JS (see https://github.com/WebAssembly/WASI/issues/82)
	emscripten_notify_memory_growth(0);
	#endif

It also skips the -sSHARED_MEMORY acorn pass, which adds some overhead too.

emscripten/tools/acorn-optimizer.mjs

Lines 1081 to 1084 in d1fbb02

	// Instrument heap accesses to call growMemViews helper function, which allows
	// pthreads + memory growth to work (we check if the memory was grown on another thread
	// in each access), see #8365.
	function growableHeap(ast) {

Thinking about this more, since -sGROWABLE_ARRAYBUFFERS is a link-time setting only, how about making the -sGROWABLE_ARRAYBUFFERS setting internally and applying it automatically when targeting modern environments? For example, it could be enabled when someone builds with -sENVIRONMENT=node -sMIN_NODE_VERSION=260000 or -sENVIRONMENT=web -sMIN_CHROME_VERSION=144 -sMIN_FIREFOX_VERSION=145 -sMIN_SAFARI_VERSION=260200.

emscripten/tools/feature_matrix.py

Lines 143 to 151 in d1fbb02

	Feature.GROWABLE_ARRAYBUFFERS: {
	'chrome': 144,
	'firefox': 145,
	'safari': 260200,
	# Supported with flag --experimental-wasm-rab-integration (TODO: Change
	# this to unflagged version of Node.js 260000, see also the comment in
	# Feature.WASM_EXCEPTIONS above)
	'node': 240000,
	},

[sbc100]

Yes, GROWABLE_ARRAYBUFFERS should certainly be auto-enabled when the feature matrix allows is. If that isn't the case today we should fix that.

[sbc100]

I think this change should be good to go now. PTAL.

[kripken]

Perhaps explain why? We don't do this with other features afaik?

[sbc100]

I think we do do feature detection in some places.

The reason we want both approaches in this case is kind of important. There are two main cases:

1. For all users or pthreads+memory growth we probably want to use toResizableBuffer when available in all cases. It slightly fast since we don't need to rebuild the views each time the memory grows. There is very little cost to probing for, and using the features if its found.

2. For users that know that they are only targetting newer browsers they can opt in with -sGROWABLE_ARRAYBUFFERS which means we don't need run the whole growableHeap JS optimizer path (which is the thing that slows down all the HEAP accesses in normal builder). These users see even more of a benefit, but their code won't run on older browsers.

[sbc100]

For example of where we do feature detection you can see many by doing git grep "if .*globalThis" src.

In most cases we don't have setting to opt out of the feature-detection and just assume the feature is present. In some cases we can use the feature matrix to detect when the feature-detection is not needed.

In the long run I think we may just want to delete this setting (or at least make it internal) since it can be driven completely by the feature matrix.

[kripken]

For example of where we do feature detection you can see many by doing git grep "if .*globalThis" src.

Do we have feature flags for those things, though? E.g. one result is

src/lib/libembind.js:    if (!globalThis.FinalizationRegistry) {

I don't think we have a flag for that, so we have to check it.

That is, what seems new to me is Even when this setting is disabled, Emscripten will still use this feature when available - do we do that anywhere else? Normally if a user disables a setting, we don't use the feature, afaik

[sbc100]

For this feature I think we want two things:

1. We want to use it whenever we can. There is really no need to be able to completely opt out. (just like with FinalizationRegistry).
2. We want to be able to create a built where we assume its always present (because we want to be able to opt out of the cost of using growableHeap JS transform.

We maybe its not something we have done before (both features detection and a setting). But I certainly think its justified in this case.

Unless you have any other ideas about how to better take advantage of this by default?

[sbc100]

In other words, a user specifies -sGROWABLE_ARRAYBUFFERS=0 what they are saying is "support browser that don't have this feature", not "ignore this feature, even when available".

[sbc100]

This is currently sitting on top of #27117 and #27116

[sbc100]

I've rephrased both the ChangeLog entry and the settings documentation to better describe the default behaviour and why you might still want to opt in using the explicit settings.