src: implement structuredClone in native

[joyeecheung]

Simplify the implementation by implementing it directly in C++. This improves performance and also makes structuredClone supported in custom snapshots.

Local benchmark numbers:

                                                    confidence improvement accuracy (*)   (**)  (***)
misc/structured-clone.js n=10000 type='arraybuffer'        ***     12.79 %       ±1.72% ±2.29% ±2.99%
misc/structured-clone.js n=10000 type='object'             ***      7.65 %       ±2.22% ±2.96% ±3.85%
misc/structured-clone.js n=10000 type='string'             ***     75.01 %       ±3.84% ±5.14% ±6.75%

[nodejs-github-bot]

Review requested:

• @nodejs/crypto
• @nodejs/net
• @nodejs/startup

[nodejs-github-bot]

CI: https://ci.nodejs.org/job/node-test-pull-request/55129/

[KhafraDev]

will this fix #49940 too?

[mcollina]

lgtm

Am I correct in assuming this will improve all messaging through worker threads?

[benjamingr]

@mcollina no, if you look at the changes this instead of creating a MessageChannel object in JS land creates it in C++ land - basically moving that part from JS to C++, see https://github.com/nodejs/node/pull/50330/files#diff-512ab8348327408c9a5ba3f7c60d8f8977a672a22b96345b8cfc2562936062f5R1582-R1583

[joyeecheung]

FYI this is not yet ready because I want to see if we can just avoid the message ports all together without doing a lot of refactoring (there are a lot of code in place to check that the port isn't in the arguments, which then rely on having a port instance to check on) - if not, I'll just try getting this in first before following up with a PR to get rid of the message ports

[joyeecheung]

From what I can tell simply using the existing Message::Serialize/Message::Deserialize should yield equivalent results. This should also get rid of the previous peculiar behavior of emitting deserialization errors as messageerror events instead of throwing them directly.

[nodejs-github-bot]

CI: https://ci.nodejs.org/job/node-test-pull-request/55182/

[joyeecheung]

will this fix #49940 too?

I don't think so, the assertion comes from the ReadIterable implementation and that's still unfixed - on the other hand it might be better to just implement that method in JS land and do a glue of structuredClone with that method. This calls into JS so many times that doing it in C++ would be slower. I can do that as a follow-up.

[joyeecheung]

I removed the messaging namespace rename (this should still be done in another PR though) and the BindingData because it now no longer relies on MessagePorts. The benchmark numbers are improved a bit too due to the removal of unnecessary hoops:

                                                    confidence improvement accuracy (*)   (**)  (***)
misc/structured-clone.js n=10000 type='arraybuffer'        ***     12.79 %       ±1.72% ±2.29% ±2.99%
misc/structured-clone.js n=10000 type='object'             ***      7.65 %       ±2.22% ±2.96% ±3.85%
misc/structured-clone.js n=10000 type='string'             ***     75.01 %       ±3.84% ±5.14% ±6.75%

This should be ready for review now - I'd appreciate another pair of eyeballs to confirm that this still yields equivalent results.

[nodejs-github-bot]

CI: https://ci.nodejs.org/job/node-test-pull-request/55186/

[aduh95]

Can you please update the message in the linter error:

node/lib/.eslintrc.yaml

Lines 174 to 175 in fd21429

	- name: structuredClone
	message: Use `const { structuredClone } = require('internal/structured_clone');` instead of the global.

[nodejs-github-bot]

CI: https://ci.nodejs.org/job/node-test-pull-request/55224/

[nodejs-github-bot]

CI: https://ci.nodejs.org/job/node-test-pull-request/55232/

[nodejs-github-bot]

Landed in c3a41d8