otel-thread-ctx: publish V8 + ObjectWrap layout constants for readers#375
Open
szegedi wants to merge 1 commit into
Open
otel-thread-ctx: publish V8 + ObjectWrap layout constants for readers#375szegedi wants to merge 1 commit into
szegedi wants to merge 1 commit into
Conversation
Extends the OTEP-4719 process-context attributes emitted by
getProcessContextAttributes with three new entries an out-of-process
eBPF reader needs to walk from our TLS discovery struct to the actual
OTEP-4947 record:
- threadlocal.native_wrap_fields_offset — sizeof(node::ObjectWrap).
Given a pointer to a CtxWrap fetched via wrapped_object_offset, add
this to reach CtxWrap::record_.
- threadlocal.js_map_table_offset — offset within a V8 JSMap object of
the tagged pointer to its backing OrderedHashMap table
(JSCollection::kTableOffset in V8, 0x18).
- threadlocal.ordered_hash_map_header_size — size of the header
preceding the element_count / deleted_element_count / n_buckets
fields inside an OrderedHashMap (0x10).
Without these, a reader implementing the Node.js schema would have to
hardcode them itself and re-verify them per V8 version. Keeping the
constants in the addon puts one source of truth close to V8. The two
V8 internal offsets are not exposed in V8's public headers
(v8-internal.h); they live in Node's private V8 tree
(deps/v8/src/objects/{js-collection,ordered-hash-table}.h) — we cite
those paths in the code comments so a future V8 layout change has a
clear pointer to what to re-check.
New non-Linux fallback values match the Linux ones (24 / 0x18 / 0x10);
the reader contract is Linux-only per the OTEP anyway, so this just
keeps the exported surface consistent in shape across platforms.
Overall package sizeSelf size: 2.41 MB Dependency sizes| name | version | self size | total size | |------|---------|-----------|------------| | pprof-format | 2.2.2 | 500.53 kB | 500.53 kB | | source-map | 0.7.6 | 185.63 kB | 185.63 kB | | node-gyp-build | 4.8.4 | 13.86 kB | 13.86 kB |🤖 This report was automatically generated by heaviest-objects-in-the-universe |
|
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
1 participant
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.
Summary
Extends the OTEP-4719 process-context attributes published by
getProcessContextAttributeswith three new keys an out-of-process eBPF reader needs to walk from our TLS discovery struct all the way to the OTEP-4947 record:threadlocal.native_wrap_fields_offset—sizeof(node::ObjectWrap). Given aCtxWrap*fetched viawrapped_object_offset, add this to reachCtxWrap::record_.threadlocal.js_map_table_offset— offset within a V8JSMapof the tagged pointer to its backingOrderedHashMap(0x18).threadlocal.ordered_hash_map_header_size— size of the header preceding theelement_count/deleted_element_count/n_bucketsfields inside anOrderedHashMap(0x10).Without these a reader would have to hardcode them and re-verify per V8 version. Keeping them in the addon puts one source of truth close to V8. The two V8 internal offsets aren't exposed in V8's public headers; the code comments cite the Node.js private V8 source paths (
deps/v8/src/objects/{js-collection,ordered-hash-table}.h) so a future V8 layout change has a clear pointer to what to re-check.Motivated by planning an eBPF Node.js schema reader on top of open-telemetry/opentelemetry-ebpf-profiler#1229; the parca-dev fork already has a similar walker that hardcodes these values in eBPF (
native_custom_labels.h:304).Test plan
npm run test:docker) — 152 passing, no regressions.returns the expected shapetest now asserts the three new keys are present with expected values and updates the sorted-keys list.