src: split out per-binding state from Environment #32538
Conversation
nodejs-github-bot
added
c++
|
CI: https://ci.nodejs.org/job/node-test-pull-request/30174/ (:heavy_check_mark:) |
|
CI after rebase: https://ci.nodejs.org/job/node-test-pull-request/30268/ |
Enable the state associated with the individual bindings, e.g. fs or http2, to be moved out of the Environment class, in order for these to be more modular and for Environment to be come less of a collection of random data fields. Do this by using a BaseObject as the data for callbacks, which can hold the per-binding state. By default, no per-binding state is available, although that can be configured when setting up the binding.
Moves state that is specific to HTTP/2 into the HTTP/2 implementation as a cleanup.
Moves state that is specific to the `v8` binding into the `v8` binding implementation as a cleanup.
Moves state that is specific to HTTP/1 into the HTTP/1 implementation as a cleanup.
Moves state that is specific to the `fs` binding into the `fs` binding implementation as a cleanup.
addaleax
added
the
author ready
Enable the state associated with the individual bindings, e.g. fs or http2, to be moved out of the Environment class, in order for these to be more modular and for Environment to be come less of a collection of random data fields. Do this by using a BaseObject as the data for callbacks, which can hold the per-binding state. By default, no per-binding state is available, although that can be configured when setting up the binding. PR-URL: #32538 Reviewed-By: James M Snell <[email protected]>
Moves state that is specific to HTTP/2 into the HTTP/2 implementation as a cleanup. PR-URL: #32538 Reviewed-By: James M Snell <[email protected]>
Moves state that is specific to the `v8` binding into the `v8` binding implementation as a cleanup. PR-URL: #32538 Reviewed-By: James M Snell <[email protected]>
Moves state that is specific to HTTP/1 into the HTTP/1 implementation as a cleanup. PR-URL: #32538 Reviewed-By: James M Snell <[email protected]>
Moves state that is specific to the `fs` binding into the `fs` binding implementation as a cleanup. PR-URL: #32538 Reviewed-By: James M Snell <[email protected]>
PR-URL: #32538 Reviewed-By: James M Snell <[email protected]>
|
Landed in c2aedd0...6d6de56 |
Enable the state associated with the individual bindings, e.g. fs or http2, to be moved out of the Environment class, in order for these to be more modular and for Environment to be come less of a collection of random data fields. Do this by using a BaseObject as the data for callbacks, which can hold the per-binding state. By default, no per-binding state is available, although that can be configured when setting up the binding. PR-URL: #32538 Reviewed-By: James M Snell <[email protected]>
Moves state that is specific to HTTP/2 into the HTTP/2 implementation as a cleanup. PR-URL: #32538 Reviewed-By: James M Snell <[email protected]>
Moves state that is specific to the `v8` binding into the `v8` binding implementation as a cleanup. PR-URL: #32538 Reviewed-By: James M Snell <[email protected]>
Moves state that is specific to HTTP/1 into the HTTP/1 implementation as a cleanup. PR-URL: #32538 Reviewed-By: James M Snell <[email protected]>
Moves state that is specific to the `fs` binding into the `fs` binding implementation as a cleanup. PR-URL: #32538 Reviewed-By: James M Snell <[email protected]>
PR-URL: #32538 Reviewed-By: James M Snell <[email protected]>
| v8::Local<v8::Function> ctor; | ||
| v8::Local<v8::Object> obj; | ||
| if (!as_callback_data_template()->GetFunction(context()).ToLocal(&ctor) || | ||
| !ctor->NewInstance(context()).ToLocal(&obj)) { |
There was a problem hiding this comment.
Sorry for noticing this late - but I came across this change after a recent rebase, and I think this constraint about BaseObject is incorrect (see #26382 (comment)). Context-independent templates should not point to context-dependent objects, but now every templates created by Environment::FunctionTemplate, which are supposed to be context-independent, point to different callback data that are context-dependent v8::Objects that point to BaseObjects, making the templates non-snapshottable (and theoratically just incorrect, but this is only validated by V8's serializer and not at runtime). This was already violated by #26382 and this PR just splits one context-dependent callback data into multiple context-dependent ones, and force them to be that way since BaseObjects are...associated with v8::Object (which have to be context-dependent due to references to the constructors on the prototype chain).
There was a problem hiding this comment.
Note that even before #26382, when we were using v8::External, it was still somewhat limited - by obtaining the data directly through whatever passed into FunctiontTemplate::New, we'll always end up with the same set of callback data in the function template callback even if we switch the invoking context. This PR only makes the binding data variable by context, but it ties the FunctionTemplates to the set of the data created by the main context. If the intention is to make the binding data variable by the invoking context, (for example, so that different vm contexts have different set of builtins), we need to associate the binding data with the contexts and obtain them from there (e.g. through embedder slots, or private properties on the global object, something like GetBindingData<T>(args.GetIsolate()->GetCurrentContext())), instead of associating them with and and obtaining them from the function template callback data (Unwrap<T>(args.Data()) currently being done here), since there's always only one set of data per function template.
There was a problem hiding this comment.
@joyeecheung Yeah, I know about these issues, but this PR doesn’t really seem to make anything worse?
There is a commit in #32761 that would switch this back to using Externals for snapshotting, if we don’t end up with a better solution.
If the intention is to make the binding data variable by the invoking context, (for example, so that different vm contexts have different set of builtins), we need to associate the binding data with the contexts and obtain them from there (e.g. through embedder slots, or private properties on the global object, something like
GetBindingData<T>(args.GetIsolate()->GetCurrentContext())), instead of associating them with and and obtaining them from the function template callback data (Unwrap<T>(args.Data())currently being done here), since there's always only one set of data per function template.
Err, yeah, we could do that, but if you look it that way we’re just using FunctionTemplates and ObjectTemplates in a wrong way to begin with. It would be nicer if we could just create context-dependent templates, I would say.
There was a problem hiding this comment.
… or, even better, if we could provide data to the per-context instantiations of the templates, separately.
There was a problem hiding this comment.
Yeah, I know about these issues, but this PR doesn’t really seem to make anything worse?
I think this makes it worse in that it now forces the FunctionTemplates to be associated with context-dependent BaseObjects with the BindingData machinery. In addition BaseObject implicitly implies that the object is tied to the main context. If we were to add an indirection, we could add an indirection based on v8::External directly, but an indirection based on BaseObject(which in turn relies on Object) still doesn't make too much sense to me.
It would be nicer if we could just create context-dependent templates, I would say.
From previous discussions I think that was discouraged and it is preferred to obtain the properties from contexts. FunctionTemplates and ObjectTemplates essentially belong to the isolate while the Function and Object instantiated from them belong to the context.
There was a problem hiding this comment.
Yeah, I know about these issues, but this PR doesn’t really seem to make anything worse?
I think this makes it worse in that it now forces the FunctionTemplates to be associated with context-dependent
BaseObjects with theBindingDatamachinery.
… but previously it was also associated with a context-dependent object?
In addition
BaseObjectimplicitly implies that the object is tied to the main context
In what way? We can and do create BaseObjects in core that are associated with Contexts coming from vm.createContext().
If we were to add an indirection, we could add an indirection based on
v8::Externaldirectly, but an indirection based onBaseObject(which in turn relies onObject) still doesn't make too much sense to me.
I’m not sure what you have in mind, but as said above, #32761 does contain a commit that would switch this back to v8::External for snapshotting.
It would be nicer if we could just create context-dependent templates, I would say.
From previous discussions I think that was discouraged and it is preferred to obtain the properties from contexts.
Yeah, hence the addition that it would be even better for the data associated with the template to be set or filled per-context.
FunctionTemplates andObjectTemplatesessentially belong to the isolate while theFunctionandObjectinstantiated from them belong to the context.
Yeah, I know. I don’t think we’re disagreeing here.
targos
added
backport-requested-v12.x
and removed
author ready
src: make creating per-binding data structures easier
Enable the state associated with the individual bindings, e.g. fs or
http2, to be moved out of the Environment class, in order for these
to be more modular and for Environment to be come less of a collection
of random data fields.
Do this by using a BaseObject as the data for callbacks, which can hold
the per-binding state. By default, no per-binding state is available,
although that can be configured when setting up the binding.
src: move HTTP/2 state out of Environment
Moves state that is specific to HTTP/2 into the HTTP/2 implementation
as a cleanup.
src: move v8 stats buffers out of Environment
Moves state that is specific to the
v8binding into thev8binding implementation as a cleanup.src: move http parser state out of Environment
Moves state that is specific to HTTP/1 into the HTTP/1 implementation
as a cleanup.
src: move fs state out of Environment
Moves state that is specific to the
fsbinding into thefsbinding implementation as a cleanup.src,doc: add documentation for per-binding state pattern
Checklist
make -j4 test(UNIX), orvcbuild test(Windows) passes