feat: v8 version 11.1.277.17 #219
Open
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This does not incorporate catalyst libraries.
FIXME: Remove this the handle visitor class entirely if we can't use it anymore.
Make it a bit easier to identify what object is being allocated by MakeGarbageCollected while logging
…fields or v8::Externals Mostly a debugging tool, we can revert this
Previously extended class constructors stored their CacheItem in a single InternalField, and the CacheItem was retained by the Caches collection for the Isolate. Consider adding a separate wrapper type, or a flag to the ObjCDataWrapper struct, to indicate the disposal semantics --- However so far I don't think this is an issue.
I'm not entirely positive this is actually used anywhere, could not find it in the diff
This reverts commit d5d9f30. This change was not actually used by anything in the staging area
This change replaces the v8 root/persistent handle in the ReferenceWrapper with a traced value, which should allow it to be collected more easily, and fit in better with the general approach we're following here. It does still use a nullable heap-allocated pointer to a TracedValue, in order to have somewhat consistent behaviour with the previous version.
This is a minor change, mostly involving refactors. The gist of it is, Pointers are GC'd structures, and the update allows them to be traced correctly. It is in some ways a bit cleaner, but should be semantiaclly equivalent to the original version. There is a downside in that the result of the Pointer() constructor will now be slightly larger than previously.
The mixup between having a wrappable block/function type managed by CPPGC, while also using referencing the value with a v8::External associated with the function, caused a bit of an issue. This is an area where potentially using GC-able wrappable types is an error, as v8 currently does not make any effort to keep the value alive via the FunctionTemplate's data slot. However, given that the JS value should live as long as the API function, for now it may be a moot point. We should revisit this later.
This is one of the larger changes to the codebase --- As usual, there is a refactoring related to things such as the use of v8::Externals, which are now replaced by JSObjects with 2 embedder slots suitable for holding CPPGC values and tracing them effectively. The old approach to retaining the "parent" struct of a StructWrapper is simplified to rely on a traced value, avoiding the need for shared pointer tracking.
Following the usual pattern of cleanup and replacing v8::Externals and explicit lifetime management with GarbageCollected CPPGC types and JS wrapper objects.
Following a similar pattern to other changes.
This reverts commit f1adc76.
Because CPPGC grants us the ability to handle finalization of script wrpapable types in a GarbageCollected<T>'s destructor, this allows us to greatly simplify how this works. However, currently there are a lot of interactions between the instance caching subsystem and object manager, and there are tests which verify this behaviour. For its part, __releaseNativeCounterpart() should still behave somewhat consistently with how it did, in its previous incarnation, although it likely is buggy to some degree, particularly if native data is shared between multiple threads. It's a work in progress to fix this and further simplify it. However, we do need to come up with a more sensible mechanism for properly retaining native data, and cleaning up JS wrappers.
This reverts commit 2423d5e. This change breaks build of nsultimatetabsetup
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
No description provided.