-
-
Notifications
You must be signed in to change notification settings - Fork 136
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Remove weak callback from __postFrameCallback cache (#1755)
* feat: Remove NDK profiler BREAKING CHANGE: __startNDKProfiler() and __stopNDKProfiler() global bindings no longer available. The NDK profiler was not functional, since nothing in the build process defined the NDK_PROFILER_ENABLED preprocessor symbol. The start and stop functions were already no-ops. * chore: Remove outdated comment RunMicrotasks no longer exists, it's already been replaced in the code with PerformMicrotaskCheckpoint. * chore: Use unique_ptr for NewBackingStore in byte buffers V8 doc: https://docs.google.com/document/d/1sTc_jRL87Fu175Holm5SV0kajkseGl2r8ifGY76G35k/edit The V8 usage examples show unique_ptr here; it probably doesn't matter much, but we don't need the backing store after creating the ArrayBuffer, and I believe shared_ptr is slightly more overhead than unique_ptr. For convenience, replace the manual empty deleter for direct buffers with v8::BackingStore::EmptyDeleter. * chore: Remove weak finalizer callback from __postFrameCallback() Weak finalizer callbacks are going away in V8 11.x, so we have to remove this one. Luckily, a finalizer callback is not necessary - it's never needed to prevent the frame callback from being collected. However, a weak callback is not necessary in the first place. We can just clean up the cache entry after the callback is executed, since it is only executed once. Note that the call to erase() destructs the FrameCallbackCacheEntry instance, making `entry` a dangling pointer, so don't use it after the erase(). There's probably a safer way to do this, although the way that first occurred to me (pass the key to the callback instead of the entry, and then use std::unordered_map::extract()) is not available on robin_hood::unordered_map. * fix: Make sure frame callbacks are not ignored There was a bug where __postFrameCallback() would not always cause the callback to be called. Without initializing `removed`, sometimes it would have a nonzero value, so the callback would be ignored. * chore: Clear callback caches' persistent handles in destructor Clearing the persistent handles in the destructor makes it a bit easier to deal with the cache entry's lifetime: they are cleared whenever the entry is removed from the cache. We do this for both the main thread callback cache and the frame callback cache. Adding a destructor makes the cache entries non-movable. But the only place where they were moved was when inserting them into the cache anyway. We can use C++17's try_emplace() method to insert them without having to move them. * chore: Construct FrameCallbackCacheEntry with ID This avoids the situation of forgetting to add an ID to the cache entry. * chore: Improve usage of unordered_map APIs in CallbackHandlers This fixes a few places where we can avoid double lookups: - In RunOnMainThreadFdCallback, we already have a valid iterator, so no need to look up the same key again in RemoveKey (this is the only usage of RemoveKey, so we can remove it.) (Additionally, we probably want to remove the cache entry before throwing a NativeScript exception.) - In PostFrameCallback and RemoveFrameCallback, we should not do contains() immediately followed by find(). * chore: Fix runtime typo * chore: Ignore main thread and frame callback return values We don't do anything with the return value from these callbacks, so it's OK to ignore them and not convert them to a local handle.
- Loading branch information
Showing
6 changed files
with
49 additions
and
133 deletions.
There are no files selected for viewing
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 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 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 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 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 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