Repository navigation
fix(android): guard MetadataNode's process-wide node caches - #130
Open
ammarahm-ed wants to merge 1 commit into
Open
ammarahm-ed wants to merge 1 commit into
ammarahm-ed wants to merge 1 commit into
Conversation
|
Important Review skippedAuto reviews are disabled on this repository. Please check the settings in the CodeRabbit UI or the
|
This branch has not been deployed
This file contains hidden or 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
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.
Port of the
MetadataNodepart of NativeScript/android#2013, in both the Node-API and the direct runtime.s_name2NodeCache,s_name2TreeNodeCacheands_treeNode2NodeCacheare process-wide maps. Every runtime thread, including each worker, reads and inserts into them when it wraps a Java object, and nothing guarded them. A concurrent insert that rehashes arobin_hoodmap while another thread reads it is a data race that can crash or return a stale node.They are now guarded by one
s_nodeCacheMutex, held only for the map access and never across the metadata reader or aMetadataNodeconstructor. When two threads resolve the same class at once, both may build a node and the first one to insert wins; the loser is deleted before it is published.GetOrCreateTreeNodeByName,GetOrCreateandGetOrCreateInternalare rewritten around that, with the same results as before for a single thread.This does not touch
MetadataReader, which mutates the metadata tree while calling back into Java and needs its own design (see below).Results
V8 release build on a Sony SO-01M (Android 11, arm64), AOT-compiled with
cmd package compile -m speed. One warm-up launch is discarded, then 5 launches; values are the median ns per call. This is a correctness fix, so the number to watch is that the hot path does not get slower.Across all rows the median change is -1.0% on Node-API and -0.3% on the direct runtime, so the lock is not measurable here; individual rows move by up to about ±10%, which is this device's noise.
All cases
I could not reproduce the race on demand, so there is no before/after crash rate; the change rests on the maps being shared across threads without a lock. The Jasmine suite has not been run on this branch on its own; the stack-top result is in the PR above it.
Not ported from #2013
MetadataReaderlocking and theGetNodeByIdbounds check, which need a lock that can be released around the Java callback inGetOrCreateTreeNodeByName.Only V8 was built and run.