RGBCube/serenity
1
Fork 0
mirror of https://github.com/RGBCube/serenity synced 2025-05-20 17:55:08 +00:00
Code Issues Activity Actions

LibJS: Add bytecode instruction handles

Browse source 
This change removes the mmap inside of Block in favor of a growing
vector of bytes. This is favorable for two reasons:
  - We don't take more space than we need
  - There is no limit to the growth of the vector (previously, if
    the Block overstepped its 64kb boundary, it would just crash)

However, if that vector happens to resize, any pointer pointing into
that vector would become invalid. To avoid this, this commit adds an
InstructionHandle<Op> class which just stores a block and an offset
into that block.
This commit is contained in:
Matthew Olsson 2021-06-08 14:46:46 -07:00 • committed by Andreas Kling
parent 83be39c91a
commit a01bd35c67
8 changed files with 81 additions and 79 deletions
Download patch file Download diff file Expand all files Collapse all files

28
Userland/Libraries/LibJS/Bytecode/Block.cpp
View file

@ -4,10 +4,8 @@
* SPDX-License-Identifier: BSD-2-Clause
*/
#include <AK/String.h>
#include <LibJS/Bytecode/Block.h>
#include <LibJS/Bytecode/Op.h>
#include <sys/mman.h>
namespace JS::Bytecode {
@ -16,16 +14,6 @@ NonnullOwnPtr<Block> Block::create()
return adopt_own(*new Block);
}
Block::Block()
{
// FIXME: This is not the smartest solution ever. Find something cleverer!
// The main issue we're working around here is that we don't want pointers into the bytecode stream to become invalidated
// during code generation due to dynamic buffer resizing. Otherwise we could just use a Vector.
m_buffer_capacity = 64 * KiB;
m_buffer = (u8*)mmap(nullptr, m_buffer_capacity, PROT_READ | PROT_WRITE, MAP_ANONYMOUS | MAP_PRIVATE, 0, 0);
VERIFY(m_buffer != MAP_FAILED);
}
Block::~Block()
{
Bytecode::InstructionStreamIterator it(instruction_stream());
@ -34,16 +22,6 @@ Block::~Block()
++it;
Instruction::destroy(const_cast<Instruction&>(to_destroy));
}
munmap(m_buffer, m_buffer_capacity);
}
void Block::seal()
{
// FIXME: mprotect the instruction stream as PROT_READ
// This is currently not possible because instructions can have destructors (that clean up strings)
// Instructions should instead be destructor-less and refer to strings in a string table on the Bytecode::Block.
// It also doesn't work because instructions that have String members use RefPtr internally which must be in writable memory.
}
void Block::dump() const
@ -55,12 +33,6 @@ void Block::dump() const
}
}
void Block::grow(size_t additional_size)
{
m_buffer_size += additional_size;
VERIFY(m_buffer_size <= m_buffer_capacity);
}
void InstructionStreamIterator::operator++()
{
m_offset += dereference().length();