The binding data holds references to the AliasedBuffers directly
from their wrappers which already ensures that the AliasedBuffers
won't be accessed when the wrappers are GC'ed. So we can just
make the global references to the AliasedBuffers weak. This way
we can simply deserialize the typed arrays when deserialize the
binding data and avoid the extra Object::Set() calls. It also
eliminates the caveat in the JS land where aliased buffers must
be dynamically read from the binding.
PR-URL: https://github.com/nodejs/node/pull/47354
Refs: https://github.com/nodejs/node/issues/47353
Reviewed-By: Chengzhong Wu <legendecas@gmail.com>
Locally the hashing of the binding names sometimes has significant
presence in the profile of bindings, because there can be collisions,
which makes the cost of adding a new binding data non-trivial,
but it's wasteful to spend time on hashing them or dealing with
collisions at all, since we can just use the EmbedderObjectType
enum as the key, as the string names are not actually used beyond
debugging purposes and can be easily matched with a macro.
And since we can just use the enum as the key, we do not even
need the map and can just use an array with the enum as indices
for the lookup.
PR-URL: https://github.com/nodejs/node/pull/46620
Reviewed-By: Matteo Collina <matteo.collina@gmail.com>
Reviewed-By: Anna Henningsen <anna@addaleax.net>
Reviewed-By: Chengzhong Wu <legendecas@gmail.com>
Instead of iterating over the bindings, iterate over the base
objects that are snapshottable. This allows us to snapshot
base objects that are not bindings. In addition this refactors
the InternalFieldInfo class to eliminate potential undefined
behaviors, and renames it to InternalFieldInfoBase.
The {de}serialize callbacks now expect a InternalFieldInfo struct
nested in Snapshotable classes that can be used to carry
serialization data around. This allows us to create structs
inheriting from InternalFieldInfo for Snapshotable objects
that need custom fields.
PR-URL: https://github.com/nodejs/node/pull/44192
Refs: https://github.com/nodejs/node/issues/37476
Reviewed-By: Anna Henningsen <anna@addaleax.net>
Reviewed-By: Chengzhong Wu <legendecas@gmail.com>
1. Put the v8 binding data class into a header so we can reuse
the class definition during deserialization.
2. Put the v8 binding code into node::v8_utils namespace for
clarity.
3. Move the binding data property initialization into its
constructor so that we can reuse it during deserialization
4. Reorder the v8 binding initialization so that we don't
unnecessarily initialize the properties in a loop
PR-URL: https://github.com/nodejs/node/pull/37112
Refs: https://github.com/nodejs/node/pull/36943
Reviewed-By: Juan José Arboleda <soyjuanarbol@gmail.com>
Joyee Cheung