allocUnsafe is useless since 24

[ChALkeR]

See #60399 (comment)

What happed to allocUnsafe - does that work at all in 24+?

Since 24.0.0, there is no observable perf difference between alloc and allocUnsafe on large arrays, and allocUnsafe always appears to be zero-filled

In that case places relying on allocUnsafe and then fill would be ~2x faster (or more) if they just used alloc instead of allocUnsafe in the first place

E.g. Buffer.concat([Buffer.alloc(0)], 1e6) is ~10x faster with .alloc instead of .allocUnsafe + .fill, and there appears to be no regression from that change on other Buffer.concat usage

allocUnsafe should be either fixed to be faster than alloc or should be replaced with alloc everywhere (that will simplify things) and deprecated whatsoever

[ChALkeR]

Seems like GetZeroFillToggle is never called outside of snapshots?

[ChALkeR]

Note: since 24 is entering LTS tomorrow per schedule, I don't think the current behavior (i.e. zero-filling allocUnsafe) should be ever changed there

[ChALkeR]

This logic does not work:

node/lib/internal/buffer.js

Lines 1097 to 1102 in 3c8c1ef

	if (isBuildingSnapshot()) {
	// Reset the toggle so that after serialization, we'll re-create a real
	// toggle connected to the C++ one via getZeroFillToggle().
	addAfterUserSerializeCallback(() => {
	zeroFill = undefined;
	});

Manually ensuring that createUnsafeBuffer in fact calls getZeroFillToggle on the first time makes allocUnsafe actually work

Upd: b2405e9 (#55337) seems to be the first commit where the issue surfaced

[ChALkeR]

cc @nodejs/buffer and @nodejs/performance perhaps

[ChALkeR]

I'm starting to think that allocUnsafe should be just kept as zero-fill (officially, as de-facto it already is), given that no one apparently even noticed it was zero-filling for half a year (i.e. there seem to be no reports)

Is restoring/maintaining it even worth the whole complexity and security concerns?

There are already two full major version branches of Node.js (24.x and 25.x) where on each version allocUnsafe is zero-filled

At this point reverting that might be a semver-major

Upd: the observable difference between alloc and allocUnsafe currently is that alloc is not pooled while allocUnsafe is pooled

[anonrig]

cc @nodejs/tsc

[ronag]

We should fix this. In what node version did it break?

[ronag]

@joyeecheung

[mcollina]

I think we should fix whatever happened to allocUnsafe.

No one noticed because no one upgraded yet any production load. We got regression 18->20 when 18 went out of LTS.

[ChALkeR]

We should fix this. In what node version did it break?

As mentioned in the issue, 24.0.0
More specifically, #55337

[ChALkeR]

I think we should fix whatever happened to allocUnsafe.

That should happen at least before it's labeled as LTS then
It might have significant security and stability implications as code might already start depending on it zero-filling

Consumers don't read the docs if code appears to work (e.g.: the memcpy/memmove fallout, memcmp vuln in MySQL/MariaDB)

There are people who started using Node.js on 24.x and never dealt with previous branches with unsafe memory behavior
Removing zero-filling would be a breaking change for them

There are libs and apps which were developed and tested entirely on 24.x with zero-filling

It might be the lesser evil though if perf impact is significant and reintroducing unsafe memory lands before LTS

[ChALkeR]

There seems to be no significant usage of allocUnsafe introduced internally since that change, so at least all internal usage should be already tested without zero-filling enabled:

% grep -rl allocUnsafe lib | xargs -n1 git blame | grep allocUnsafe | grep 2025
5335c101a96b (James M Snell 2025-06-29 19:36:38 -0700  50) const kEmptyBuffer = Buffer.allocUnsafe(0);