src: use object to pass Environment to functions

[addaleax]

Use a v8::Object with an internal field, rather than a v8::External.

On a GetReturnValue().Set(Environment::GetCurrent(args) == nullptr)
noop function, this benchmarks as a ~60 % speedup, as calls to
obj->GetAlignedPointerFromInternalField() can be inlined.

This also makes breaking up some pieces of the Environment class
into per-native-binding data easier, if we want to pursue that path
in the future.

Checklist

• make -j4 test (UNIX), or vcbuild test (Windows) passes
• commit message follows commit guidelines

[nodejs-github-bot]

@addaleax build started: https://ci.nodejs.org/blue/organizations/jenkins/node-test-pull-request-lite-pipeline/detail/node-test-pull-request-lite-pipeline/2732/pipeline

[addaleax]

CI: https://ci.nodejs.org/job/node-test-pull-request/21107/ (:heavy_check_mark:)

[bnoordhuis]

calls to obj->GetAlignedPointerFromInternalField() can be inlined

I suspect the reason of the performance improvement is less indirection.

A v8::External is very similar to a v8::Object but it boxes the pointer inside a v8::internal::Foreign instance in order that unaligned pointers can be stored. That additional indirection comes at a cost.

I suppose V8 could optimize the box away most of the time by having two different External types internally, one for unboxed aligned pointers and one for boxed unaligned pointers. But I digress.

[addaleax]

@bnoordhuis Yeah, that makes sense.

[addaleax]

Landed in 955be86

[joyeecheung]

This is currently blocking the serialization of Environment, because the FunctionTemplates we create reference the callback data that are now context-dependent, but templates should be context-independent (that is, we now reference context-dependent objects from context-independent objects).

To unblock the snapshot integration, we need to go back to v8::External - should we wait until the performance diff is addressed in the upstream? I could try #26382 (review) and see if that solves the performance issue first.

[addaleax]

@joyeecheung So, I’m unfortunately only seeing your comment now, but I think it still deserves a reply.

What you’re saying sounds like a defect in the V8 API to me. If templates are supposed to be context-independent, and the only way to associate data with C++ binding callbacks is to pass a Local<Value>, then that doesn’t leave much room for what kind of data can be associated with the callback. Rather than going back to v8::External and improving performance there, one possibility I’d prefer is the ability to pass a more general Local<Data>, which can also be an ObjectTemplate, and then fill the internal slots of those object template’s instances after the functions have been instantiated.

As the commit message hints at, my main motivation here wasn’t actually the performance improvement, but rather I was trying to open up the possibility to make our internals a bit more flexible by allowing associating more than one item of data with the callback. (I’m assuming that that can also be done another way, using a v8::External and an additional layer of indirection if we so choose.) I had a PoC written up for that, and I think that might now turn out to be useful for addressing #28823 – feel free to ping me somewhere if you’d like to talk more about this, it’s definitely not something I had in mind when originally writing this PR.

[joyeecheung]

I’d prefer is the ability to pass a more general Local, which can also be an ObjectTemplate, and then fill the internal slots of those object template’s instances after the functions have been instantiated.

As long as what we have in ENVIRONMENT_STRONG_PERSISTENT_TEMPLATES and what they hold reference to as data are really context-independent we should be good here. Although with Local<Data> as the data we still need to be careful that they should be context-independent or otherwise we still cannot add them to the snapshot.

I was trying to open up the possibility to make our internals a bit more flexible by allowing associating more than one item of data with the callback.

It's difficult for me to see how allowing a Local<Data> instead of a Local<Value> makes a difference here...? If that data associated with the template consists of JS objects, then it's still context-dependent and would still crash the snapshot creator when we traverse them from the supposedly context-independent templates. If that data associated with the template consists of just blobs of non-JS data then I suppose composing them into a C++ construct that gets referenced by v8::External should be already enough..

I'll rebase my snapshot prototype and post it here for testing when I am back from vacation - the last time I tried, after I reverted this PR it only crashed until after the templates were traversed in the snapshot creator (due to something else I needed to fix..that I could not remember). With this PR it crashed during the traversal of the templates. So if your POC works it should once again crash at some point later.