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&.
This commit is contained in:
Shannon Booth 2024-11-14 20:22:33 +13:00 committed by Andreas Kling
parent ae6d105f41
commit c2988a7dd5
Notes: github-actions[bot] 2024-11-14 14:39:37 +00:00
27 changed files with 346 additions and 296 deletions

View file

@ -37,16 +37,16 @@ HeapBlock::HeapBlock(Heap& heap, CellAllocator& cell_allocator, size_t cell_size
ASAN_POISON_MEMORY_REGION(m_storage, block_size - sizeof(HeapBlock));
}
void HeapBlock::deallocate(Cell* cell)
void HeapBlock::deallocate(CellImpl* cell)
{
VERIFY(is_valid_cell_pointer(cell));
VERIFY(!m_freelist || is_valid_cell_pointer(m_freelist));
VERIFY(cell->state() == Cell::State::Live);
VERIFY(cell->state() == CellImpl::State::Live);
VERIFY(!cell->is_marked());
cell->~Cell();
cell->~CellImpl();
auto* freelist_entry = new (cell) FreelistEntry();
freelist_entry->set_state(Cell::State::Dead);
freelist_entry->set_state(CellImpl::State::Dead);
freelist_entry->next = m_freelist;
m_freelist = freelist_entry;