Branch: refs/heads/main
  Home:   https://github.com/WebKit/WebKit
  Commit: 6730df1f8510e66b8bc744273178c52d72d99199
      
https://github.com/WebKit/WebKit/commit/6730df1f8510e66b8bc744273178c52d72d99199
  Author: Dan Hecht <[email protected]>
  Date:   2026-09-25 (Fri, 25 Sep 2026)

  Changed paths:
    M Source/JavaScriptCore/API/JSAPIWrapperObject.mm
    M Source/JavaScriptCore/API/glib/JSAPIWrapperObjectGLib.cpp
    M Source/JavaScriptCore/heap/Heap.cpp
    M Source/JavaScriptCore/jit/JITWorklist.cpp
    M Source/JavaScriptCore/jit/JITWorklist.h
    M Source/JavaScriptCore/runtime/FunctionExecutable.cpp
    M Source/JavaScriptCore/runtime/JSFinalizationRegistry.cpp
    M Source/JavaScriptCore/runtime/JSWeakObjectRef.cpp

  Log Message:
  -----------
  [JSC] Prepare visitChildren and marking constraints for a SlotVisitor that 
marks more than one heap
https://bugs.webkit.org/show_bug.cgi?id=325294
rdar://188409763

Reviewed by Yusuke Suzuki and Mark Lam.

Each Heap has its own Collector, and each Collector its own SlotVisitors, so 
today a visitor's VM and
Heap are always those of the cell or constraint it is working on. We want one 
Collector to mark
several heaps. Its visitors will then have no heap of their own, so code that 
asks a visitor for "its"
heap has to ask the cell or the constraint instead:

 * FunctionExecutable, JSWeakObjectRef, JSFinalizationRegistry, and the 
Objective-C and GLib
   JSAPIWrapperObject ask the cell.
 * The output constraint captures its Heap, as the other core constraints 
already do.
 * JITWorklist::visitWeakReferences takes the VM from its caller.

Asking the cell loads the VM from its block header. FunctionExecutable does so 
next to an IsoCellSet
update that reads the same header, and JSFinalizationRegistry and the API 
wrappers next to work that
costs far more. For JSWeakObjectRef the load can miss in cache; A/B testing 
showed no change.

The remaining uses of SlotVisitor::vm() and SlotVisitor::heap() ask about the 
collection rather than
a heap, and will be handled separately.

No change in behavior so covered by existing tests

* Source/JavaScriptCore/API/JSAPIWrapperObject.mm:
(JSC::JSAPIWrapperObject::visitChildrenImpl):
* Source/JavaScriptCore/API/glib/JSAPIWrapperObjectGLib.cpp:
(JSAPIWrapperObjectHandleOwner::isReachableFromOpaqueRoots):
* Source/JavaScriptCore/heap/Heap.cpp:
(JSC::Heap::clearConcurrentRetainedDataIfPossible):
* Source/JavaScriptCore/jit/JITWorklist.cpp:
(JSC::JITWorklist::visitWeakReferences):
* Source/JavaScriptCore/jit/JITWorklist.h:
* Source/JavaScriptCore/runtime/FunctionExecutable.cpp:
(JSC::FunctionExecutable::visitChildrenImpl):
(JSC::FunctionExecutable::visitOutputConstraintsImpl):
* Source/JavaScriptCore/runtime/JSFinalizationRegistry.cpp:
(JSC::JSFinalizationRegistry::visitChildrenImpl):
* Source/JavaScriptCore/runtime/JSWeakObjectRef.cpp:
(JSC::JSWeakObjectRef::visitChildrenImpl):

Canonical link: https://commits.webkit.org/321937@main



To unsubscribe from these emails, change your notification settings at 
https://github.com/WebKit/WebKit/settings/notifications

Reply via email to