Instead of copying the uv_fs_stat struct to a list of Wren numbers, we
store it directly in the Stat object. This is important because we'll
need to implement later methods like isDirectory() in C so we can use
S_ISDIR(). For that, we need to have access to the original stat data.
Gets rid of the slightly ugly loadInstruction output parameter that
gets passed around. Now a reference to a variable is a first-class
concept in the compiler.
Now, you call wrenEnsureSlots() and then wrenSetSlot___() to set up the
receiver and arguments before the call. Then wrenCall() is passed a
handle to the stub function that makes the call. After that, you can
get the result using wrenGetSlot___().
This is a little more verbose to use, but it's more flexible, simpler,
and much faster in the VM. The call benchmark is 185% of the previous
speed.
Instead, finalizers just get access to the foreign object's raw bytes.
This is deliberately limiting, since it discourages the user from
interacting with the VM in the middle of a GC.
- wrenEnsureSlots()
Lets you go the foreign slot stack to make room for a temporary work
area.
- wrenSetSlotNewList()
Creates a new empty list and stores it in a slot.
- wrenInsertInList()
Takes a value from one slot and inserts it into the list in another.
Still need more functions like getting elements from a list, removing,
etc. but this at least lets you create, populate, and return lists from
foreign methods.
This turns those functions into general-purpose functions for writing
raw C values into slots on the foreign call stack.
Writing a return just means writing a value to slot 0.
- wrenGetArgumentCount() -> wrenGetSlotCount()
- wrenGetArgument___() -> wrenGetSlot___()
Also, the get functions assert that the value is the right type instead
of checking at runtime. This puts the onus on the caller to be safe,
but maximizes performance.
This is the first step towards dynamically grown stacks. We don't want
to check for stack overflow on every single push, so we store the max
number of slots a function might need and (in later patches) ensure
at function call time that that many slots are available.
If we ever support custom string templates, we'll need to go back to
compiling them to functions. But, for now, they can be evaluated
eagerly, leading to simpler code.
This allows "%(...)" inside a string literal to interpolate the
stringified result of an expression.
It doesn't support custom interpolators or format strings, but we can
consider extending that later.
- Make sure it handles an empty gray set.
- Make sure growing the gray stack doesn't itself trigger a GC.
- Make sure it works when stress testing is enabled.
- Ensure the tests kick off a GC.
The previous GC implementation used a recursive mark method. This can
result in stack overflows when attempting to mark deeply nested objects.
This commit replaces the recursive approach with an iteritive one,
moving the state stack from the C call stack to the `WrenVM` structure.
As objects are 'grayed' they are pushed onto the VM's gray stack. When
we have grayed all of the root objects we iterate until the stack is
empty graying any obejcts which haven't been marked as dark before. At
the end of the process we clean up all unmarked objects as before.
This commit also adds a few new tests which check garbage collection by
allocating some new deeply nested objects and triggering the GC a few
times in the process.
Wren now has three classes of modules:
- The one magic "core" module that's built in and always needed.
- Auxiliary libraries like "meta" and "random". These do not have any
dependencies, so can be used even when you embed Wren inside an
application. But they're also optional and can be disabled if you
don't need them.
- CLI modules. These ones need libuv and are tied to the CLI wrapper
around the VM.
Bob Nystrom
Will Speak