Store sampling context in the AsyncContextFrame directly #255
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.
What does this PR do?:
AsyncContextFrame(ACF) object in the CPED with a proxy that has an internal field for our sample context.AsyncLocalStorageas the key will allow the sampling context object to be retrieved from JavaScript usingstorage.getStore()on that object. This opens the possibility of implementing custom contexts in dd-trace-js.Motivation:
Simplification and performance. Storing the sampling context directly in the ACF reduces the complexity of having a proxy object. We also no longer need to ensure that the proxy object is updated every time a new async context is created, thus dd-trace-js no longer needs to instrument
AsyncLocalStorage.enterWith, eliminating the need to do any work on context creation or switches.Additional Notes:
While storing the sampling context is now simpler, retrieving it from the signal handler actually got more complex, but that's a tradeoff we should make. Namely, in the signal handler now we need to chase pointers from current isolate to the hash table backing the ACF storage, and then also implement the hash table lookup-by-key. None of these data structures are published by V8, so we're doing raw memory interpretation. They would also need to be updated if V8 internally changes them. (I will probably rewrite the current code to instead declare structs that mirror the memory layout and use that.)
How to test the change?:
TBD