Skip to content

Object-op hot paths: TLS fetch density (~50% of write samples) + hot-path mutex — Phase A acceptance completion (#6759) #6809

Description

@proggeramlug

Profiling the #6759 acceptance micros on merged main (post #6800#6808) shows the residual object-op gap vs node is no longer shape/side-table probes — it is TLS-fetch density in the helper layers. On the write micro (9.6M dynamic writes to existing keys, ~1.6µs/op vs node ~0.8ns):

_tlv_get_addr (libdyld)            944 samples   ← ~50% of top-of-stack
pthread_mutex_lock/unlock          175 samples   ← hot-path mutex
_platform_memcmp                    71 samples   ← key compares (fine)

Phase A's acceptance criterion was _tlv_get_addr + LocalKey::with ≤2% of samples; the ENTRY points do fetch state() once (#6795/#6799), but each write then descends through helpers that re-fetch TLS independently — runtime_write_barrier_slot (GC flags + remembered set), arena state, interned_key_ptr/plan probes, mark_object_dynamic_shape_unknown, transition-cache access — multiplying to dozens of _tlv_get_addr calls per logical operation. The mutex samples want identifying too (prime suspect: the global string-intern table taken per write for plan keying).

Scope: thread the &'static RuntimeState (or a per-op context) DOWN through the object read/write helper stacks so one fetch serves the whole operation, audit the remaining non-state thread_local!s on those paths (GC flags/remembered set are the big ones), and get the intern mutex off the per-op path (thread-local intern cache or pre-interned plan keys). Measurement protocol + current baseline table: see the #6759 acceptance comment.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions