beenull/ladybird
1
0
Fork 0
mirror of https://github.com/LadybirdBrowser/ladybird.git synced 2024-11-22 15:40:19 +00:00
Code Issues Projects Releases Packages Wiki Activity Actions 6
ladybird/Libraries/LibGC/Cell.cpp

19 lines
318 B
C++
Raw Normal View History

LibJS: Don't directly teach the heap about the javascript VM or Realm Instead, smuggle it in as a `void*` private data and let Javascript aware code cast out that pointer to a VM&. In order to make this split, rename JS::Cell to JS::CellImpl. Once we have a LibGC, this will become GC::Cell. CellImpl then has no specific knowledge of the VM& and Realm&. That knowledge is instead put into JS::Cell, which inherits from CellImpl. JS::Cell is responsible for JavaScript's realm initialization, as well as converting of the void* private data to what it knows should be the VM&.
2024-11-14 07:22:33 +00:00
/*
* Copyright (c) 2020-2022, Andreas Kling <andreas@ladybird.org>
*
* SPDX-License-Identifier: BSD-2-Clause
*/
LibGC+Everywhere: Factor out a LibGC from LibJS Resulting in a massive rename across almost everywhere! Alongside the namespace change, we now have the following names: * JS::NonnullGCPtr -> GC::Ref * JS::GCPtr -> GC::Ptr * JS::HeapFunction -> GC::Function * JS::CellImpl -> GC::Cell * JS::Handle -> GC::Root
2024-11-14 15:01:23 +00:00
#include <LibGC/Cell.h>
#include <LibGC/NanBoxedValue.h>
LibJS: Don't directly teach the heap about the javascript VM or Realm Instead, smuggle it in as a `void*` private data and let Javascript aware code cast out that pointer to a VM&. In order to make this split, rename JS::Cell to JS::CellImpl. Once we have a LibGC, this will become GC::Cell. CellImpl then has no specific knowledge of the VM& and Realm&. That knowledge is instead put into JS::Cell, which inherits from CellImpl. JS::Cell is responsible for JavaScript's realm initialization, as well as converting of the void* private data to what it knows should be the VM&.
2024-11-14 07:22:33 +00:00
LibGC+Everywhere: Factor out a LibGC from LibJS Resulting in a massive rename across almost everywhere! Alongside the namespace change, we now have the following names: * JS::NonnullGCPtr -> GC::Ref * JS::GCPtr -> GC::Ptr * JS::HeapFunction -> GC::Function * JS::CellImpl -> GC::Cell * JS::Handle -> GC::Root
2024-11-14 15:01:23 +00:00
namespace GC {
LibJS: Don't directly teach the heap about the javascript VM or Realm Instead, smuggle it in as a `void*` private data and let Javascript aware code cast out that pointer to a VM&. In order to make this split, rename JS::Cell to JS::CellImpl. Once we have a LibGC, this will become GC::Cell. CellImpl then has no specific knowledge of the VM& and Realm&. That knowledge is instead put into JS::Cell, which inherits from CellImpl. JS::Cell is responsible for JavaScript's realm initialization, as well as converting of the void* private data to what it knows should be the VM&.
2024-11-14 07:22:33 +00:00
LibGC+Everywhere: Factor out a LibGC from LibJS Resulting in a massive rename across almost everywhere! Alongside the namespace change, we now have the following names: * JS::NonnullGCPtr -> GC::Ref * JS::GCPtr -> GC::Ptr * JS::HeapFunction -> GC::Function * JS::CellImpl -> GC::Cell * JS::Handle -> GC::Root
2024-11-14 15:01:23 +00:00
void GC::Cell::Visitor::visit(NanBoxedValue const& value)
LibJS: Don't directly teach the heap about the javascript VM or Realm Instead, smuggle it in as a `void*` private data and let Javascript aware code cast out that pointer to a VM&. In order to make this split, rename JS::Cell to JS::CellImpl. Once we have a LibGC, this will become GC::Cell. CellImpl then has no specific knowledge of the VM& and Realm&. That knowledge is instead put into JS::Cell, which inherits from CellImpl. JS::Cell is responsible for JavaScript's realm initialization, as well as converting of the void* private data to what it knows should be the VM&.
2024-11-14 07:22:33 +00:00
{
if (value.is_cell())
visit_impl(value.as_cell());
}
}
Reference in a new issue Copy permalink