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.

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.

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.