ladybird/Libraries/LibJS/Heap/Handle.cpp

/*
 * Copyright (c) 2020, Andreas Kling <andreas@ladybird.org>
 *
 * SPDX-License-Identifier: BSD-2-Clause
 */

#include <LibJS/Heap/CellImpl.h>
#include <LibJS/Heap/Handle.h>
#include <LibJS/Heap/Heap.h>

namespace JS {

HandleImpl::HandleImpl(CellImpl* cell, SourceLocation location)
    : m_cell(cell)
    , m_location(location)
{
    m_cell->heap().did_create_handle({}, *this);
}

HandleImpl::~HandleImpl()
{
    m_cell->heap().did_destroy_handle({}, *this);
}

}
LibJS: Add missing copyright headers 2020-03-18 16:21:06 -03:00			`/*`
Meta: Update my e-mail address everywhere 2024-10-04 08:19:50 -03:00			`* Copyright (c) 2020, Andreas Kling <andreas@ladybird.org>`
LibJS: Add missing copyright headers 2020-03-18 16:21:06 -03:00			`*`
Everything: Move to SPDX license identifiers in all files. SPDX License Identifiers are a more compact / standardized way of representing file license information. See: https://spdx.dev/resources/use/#identifiers This was done with the `ambr` search and replace tool. ambr --no-parent-ignore --key-from-file --rep-from-file key.txt rep.txt * 2021-04-22 05:24:48 -03:00			`* SPDX-License-Identifier: BSD-2-Clause`
LibJS: Add missing copyright headers 2020-03-18 16:21:06 -03:00			`*/`

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 04:22:33 -03:00			`#include <LibJS/Heap/CellImpl.h>`
LibJS: Add Handle<T>, a strong C++ handle for keeping GC objects alive This is pretty heavy and unoptimized, but it will do the trick for now. Basically, Heap now has a HashTable<HandleImpl> and you can call JS::make_handle(T) to construct a Handle<T> that guarantees that the pointee will always survive GC until the Handle<T> is destroyed. 2020-03-18 16:03:17 -03:00			`#include <LibJS/Heap/Handle.h>`
LibJS: Remove some unused runtime headers from Heap folder 2024-08-18 20:51:04 -03:00			`#include <LibJS/Heap/Heap.h>`
LibJS: Add Handle<T>, a strong C++ handle for keeping GC objects alive This is pretty heavy and unoptimized, but it will do the trick for now. Basically, Heap now has a HashTable<HandleImpl> and you can call JS::make_handle(T) to construct a Handle<T> that guarantees that the pointee will always survive GC until the Handle<T> is destroyed. 2020-03-18 16:03:17 -03:00
			`namespace JS {`

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 04:22:33 -03:00			`HandleImpl::HandleImpl(CellImpl* cell, SourceLocation location)`
LibJS: Add Handle<T>, a strong C++ handle for keeping GC objects alive This is pretty heavy and unoptimized, but it will do the trick for now. Basically, Heap now has a HashTable<HandleImpl> and you can call JS::make_handle(T) to construct a Handle<T> that guarantees that the pointee will always survive GC until the Handle<T> is destroyed. 2020-03-18 16:03:17 -03:00			`: m_cell(cell)`
LibJS: Add source location for Handle nodes in GC graph dumper output With this change JS::Handle root nodes will contain source location where they were constructed like: ``` "94675029575744": { "root": "Handle activate_event_handler \ serenity/Userland/Libraries/LibWeb/DOM/EventTarget.cpp:564", "class_name": "HTMLButtonElement", "edges": [ "94675025955904", "94675026899520", "94675030831168", ``` 2023-09-21 21:04:16 -03:00			`, m_location(location)`
LibJS: Add Handle<T>, a strong C++ handle for keeping GC objects alive This is pretty heavy and unoptimized, but it will do the trick for now. Basically, Heap now has a HashTable<HandleImpl> and you can call JS::make_handle(T) to construct a Handle<T> that guarantees that the pointee will always survive GC until the Handle<T> is destroyed. 2020-03-18 16:03:17 -03:00			`{`
			`m_cell->heap().did_create_handle({}, *this);`
			`}`

			`HandleImpl::~HandleImpl()`
			`{`
			`m_cell->heap().did_destroy_handle({}, *this);`
			`}`

			`}`