docs(plan): supersede the v0.5.1299 construction profile with the v0.5.1325 one (#7578) - #7581
Conversation
…5.1325 one (#7578) Three rows of the #7469 decomposition are closed. _tlv_get_addr is 1.0% (was 27.0%, #7565) and layout_forget_object 1.7-2.9% (was 14.5%, #7525/#7532); neither is a lever any more. The new top lever is typed_shape_layout_entry at ~25%, tied with write barriers. Records that #7512 is closed by #7515 and why the root cause generalises: a predicate over a synthesized-vs-source IR distinction that matched only the synthesized form was structurally unreachable for the case it documented. Flags the one #7578 row that is unexplained (js_array_length) so it is not worked from as written, with both failed isolation attempts.
|
Warning Review limit reached
Next review available in: 2 minutes You've used all free OSS reviews for now. Wait for the free limit to reset to keep reviewing this public repository. How can I continue?After more reviews become available, a review can be triggered using the To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews. How do review limits work?CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability. For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window. Please refer docs for additional details. Review details⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Plus Run ID: ⛔ Files ignored due to path filters (1)
📒 Files selected for processing (4)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
1 participant
Docs only. Keeps
docs/engine-plan.mdtrue after #7565, #7566, #7515/#7532 and #7579.Three rows of the
#7469construction decomposition are closed, and the table still presented them as the backlog:_tlv_get_addrlayout_forget_objecttyped_shape_layout_entryNothing regressed: the survivors grew as shares because everything around them collapsed. The point of the edit is that someone reading the plan for "what to work next" was being pointed at two rows that are now noise.
The new top lever is characterised rather than just named — it is not the
ValidateSlotsloop (push_clstakes thedeclarepath, confirmed in the emitted IR), so #7515/#7532 are working. It is the install, whose hit path is documented as two header bit-writes, reached through an FFI call whose every argument but the object pointer is a compile-time constant. That is the same shape #7566 just won 1.81× on.Also records that #7512 is closed by #7515, and why the root cause is worth carrying forward: the dead-field-init elision matched
Expr::PropertySet, which the compiler synthesizes for anon-shape literal constructors, while every source-levelthis.v = vlowers toExpr::PutValueSet. Nothing a user can type producesPropertySet, so the elision was structurally unreachable for the declared class it was documented as covering. An unreachable predicate passes every soundness test there is.And it flags the one #7578 row that is unexplained, so nobody works it as written:
js_array_lengthat 10–15% against a single call site executing 20,000 times in a 20M-push workload. Both of my isolation attempts failed and are recorded on the issue — varying array size moved the workload into a different GC regime, and a.length-only microbenchmark measured 1.00 ns/iter for both a 1,000- and a 10-element array, which is an empty loop rather than an O(1) proof.check_file_size.shclean. No code touched.