9 ms·

Show HN: Nova JavaScript Engine

271 points by aapoalas 2y ago

We're building a different kind of JavaScript engine, based on data-oriented design and willingness to try something quite out of left field. This is most concretely visible in our major architectural choices: 1. All data allocated on the JavaScript heap is placed into a type-specific vector. Numbers go into the numbers vector, strings into the strings vector, and so on. 2. All heap references are type-discriminated indexes: A heap number is identified by its discriminant value and the index to which it points to in the numbers vector. 3. Objects are also split up into object kind -specific vectors. Ordinary objects go into one vector, Arrays go into another, DataViews into yet another, and so on. 4. Unordinary objects' heap data does not contain ordinary object data but instead they contain an optional index to the ordinary objects vector. 5. Objects are aggressively split into parts to avoid common use-cases having to reading parts that are known to be unused. If this sounds interesting, I've written a few blog posts on the internals of Nova over in our blog, you can jump into that here: https://trynova.dev/blog/what-is-the-nova-javascript-engine https://trynova.dev/blog/what-is-the-nova-javascript-engine

Etheryte 2y ago
Architectural choices are interesting to talk about, but I think most people reading this won't have any context to compare against, me included. How does this compare to e.g. the architecture of V8? What benefits do these choices give when compared against other engines? Etc, reading through the list it's easy to nod along, but it's hard to actually have an intuition about whether these are good choices or not.
- aapoalas 2y ago
  That's a good point. The "Internals of Nova" blog posts do a bit more explicit comparisons to V8. In V8, and other production engines AFAIK, objects are variable-sized monoliths: All of their statically known data is contained in one slab. This means that for example in Node.js an empty ArrayBuffer is 96 bytes in size (IIRC). Basically, they implement the ECMASCript specification defined inheritance chain using object-oriented class inheritance.
- VPenkov 2y ago
  They seem to have a blog post on that: https://trynova.dev/blog/why-build-a-js-engine https://trynova.dev/blog/why-build-a-js-engine It reads like an experimental approach because someone decided to will it into existence. That and to see if they can achieve better performance because of the architectural choices. > Luckily, we do have an idea, a new spin on the ECMAScript specification. The starting point is data-oriented design (...) > So, when you read a cache line you should aim for the entire cache line to be used. The best data structure in the world, bar none, is the humble vector (...) > So what we want to explore is then: What sort of an engine do you get when almost everything is a vector or an index into a vector, and data structures are optimised for cache line usage? Join us in finding out (...)
  - aapoalas 2y ago
    The impetus for the engine design is indeed, as you say, "someone decided to will it into existence." A friend of mine who works in the gaming industry told me about the Entity Component System architecture and I thought: Hey, wouldn't that work for a JavaScript engine? So I decided to find out. Nova itself has already been created at that point and I was part of the project, but it was little more than a README. I then started to push it towards my vision, and the rest is not-quite-history.
    - kitd 2y ago
      A friend of mine who works in the gaming industry told me about the Entity Component System architecture and I thought: Hey, wouldn't that work for a JavaScript engine? That was the first thing I thought of when I saw your description. But the reason ECS works well is cache coherence. (Why) would a general-purpose runtime environment like a JS engine benefit from ECS? Or alternatively, have you seen performance improvements as a result?
      - aapoalas 2y ago
        I guess the opposite could also be asked: Why would a game benefit from ECS? A player in the game can do basically anything, there's no guarantee that things are always perfectly accessed in a linear order. It comes down to statistics: Large data sets in a general-purpose runtime environment are still created through parsing or looping, and they are consumed by looping. A human can manually create small data sets of entirely heterogenous data, but anything more than a 100 items is already unlikely. Finally, the garbage collector is a kind of "System" in the ECS sense. So even if the JavaScript code has managed to create very nonlinear data sets, the garbage collector will still enjoy benefits. (Tracing the data is still "pointer chasing" but when tracing we don't need to trace in the data order but can instead gather a collection of heap references we've seen, sort them in order and then trace them.)
- fastball 2y ago
  https://www.youtube.com/watch?v=5olgPdqKZ84 https://www.youtube.com/watch?v=5olgPdqKZ84
HatchedLake721 2y ago
[flagged]
- aapoalas 2y ago
  https://www.youtube.com/watch?v=-94qrgxH35M https://www.youtube.com/watch?v=-94qrgxH35M
  - mdaniel 2y ago
    Absolutely perfect clapback, well done! o/
aapoalas 2y ago
A short comparison to how V8 does these things: 1. All data in V8 is allocated into one of many heap parts: Usually new data goes into a nursery space, and if it does not get GC'd it moves to the old space. Relative position of data isn't really guaranteed at this point. 2. All heap references in V8 are true pointers or, if pointer compression is used, offsets from the heap base. 3. All objects in V8 include all the data needed for them to act as objects, and all of their data is stored in a single allocation (with the exception of properties, with some exceptions). The more specialised an object is, say an ArrayBuffer, Uint8Array, or a DataView, the bigger it has to be as the specialisation requires more data to be stored.
pavlov 2y ago
Do you have some specific application profile in mind? Sounds like this approach could be useful for games that embed a scripting engine. In that context it might be interesting to eventually see some benchmarks against usual suspects of game scripting like Lua.
- aapoalas 2y ago
  The plan is to eventually get to full ECMAScript specification compatibility, and who knows if that would then bring us to eg. the Servo browser or Deno JS runtime. In the short term, I am interested in one-shot script running scenarios where only very limited JavaScript type are needed. The engine already has a bunch of feature flags that can be turned off to disable things like ArrayBuffers and other "complex" features. I have a work-related system in mind where only JSON based types are needed, and garbage collection isn't really necessary: The code could be run once and afterwards the system could be wiped down to the initial state and re-run. I also have half-a-mind to try running Nova on an STM32 board. But that could be called a hobby project within a hobby project :)
tobr 2y ago
Apologies for an insubstantial complaint, but there are just too many things called “Nova” (or its Greek counterpart, “Neo”). I get it, it’s new, but isn’t there anything more specific or unique to reflect in the project name?
- aapoalas 2y ago
  Heh, no apology needed. It's definitely an overused name. We bikeshed the name a good few years ago and came to "Nova" from "Supernova" because space is, like, cool. Rebranding would feel weird now :) I console myself with the knowledge that most engine names are unknown anyway, and even if known they are still unsearchable (looking at you two, V8 and JSC!)
- deleted 2y ago
  [deleted]
- load1n9 2y ago
  Absolutely overused but allows for cool puns
gardaani 2y ago
Is this an experimental only JS engine or do you aim to implement the entire ECMAscript specification? I have been following the Rust Boa project, but I think that it isn't production ready, yet. https://github.com/boa-dev/boa https://github.com/boa-dev/boa
- aapoalas 2y ago
  The aim is absolutely to implement the entire ECMAScript specification. Progress has slowed down recently, as I've been both busy with other things and tied up in making the engine work with interleaved GC. A secondary aim is to have a bunch of feature flags that allows the engine to drop out support for specification parts that a particular embedder doesn't care about. That obviously fights with the "implement the entire ECMAScript specification" goal, but I just hate indexed property getters and setters with a passion and want to see them gone wherever I go. Boa is a great project and I believe it is being used in some production systems. I've met and exchanged some ideas with the main developer, Jason Williams, and even received the greatest praise that I could imagine: Boa will (or did?) take some inspiration from Nova on its GC refactoring. Nova has also copied (with proper attribution of course) a few minor parts from Boa, like whitespace skipping code for some spec abstract operations. I highly recommend keeping an eye out and using Boa if you have the chance.
lionkor 2y ago
Isn't data oriented design driven by knowing what your data accesses look like? In your engine, you're building as if you're assuming that common data access will be linear access over objects of the same type. Why?
- aapoalas 2y ago
  Yeah, know your data and how it is used. I assume that data access is mostly linear because of a few reasons: 1. All performance issues arise in loops: I at least have never seen a performance problem that could be explained by a single thing happening once. It is always a particular thing happening over and over again. 2. All loops deal with collections of data, and the collections are usually created either created manually by a human being, or are created through parsing or looping many at a time. 3. A human being can manually create a collection of maybe a hundred items manually before they get bored and stop. A collection created this way may contain data from all over the place, with data access over it being nonlinear. 4. A collection created through parsing or looping will create its data in a mostly linear fashion. Accessing the data will then also be linear. There are definitely cases where nonlinear collections exist, but these are usually either small or are created from smaller sets of linear data. eg. Think of dragging 10 lists of 1000 items to form a list of 10000 items. The entire 10000 items aren't going to be located linearly, but every 1000 items will be. So in effect, I'm betting that most hot loops do deal with linear access over objects and that loops that work over nonlinear access are not particularly hot.
  - lionkor 2y ago
    Makes sense when you put it like that, thanks very much for explaining your thought process.
ksec 2y ago
Well, Devs of V8, Spidermonkey, Webkit and GraalJS are all on HN. Hopefully they see this and all chime in.
- aapoalas 2y ago
  I hope so too :) I've contributed some minor bits of code to V8 and then worked on Nova for a year or two, but I'm still wet behind the ears compared to those folks. Any and all comments I can get from them is a blessing.
pansa2 2y ago
Does Nova include a JIT compiler? Or just an interpreter?
- aapoalas 2y ago
  Nova only has a bytecode compiler and interpreter. I do not plan on trying my hand at JIT compiling any time in the future. In this I am a follower of Ladybird's Andreas Kling and hope that JIT will not become necessary.
  - mightyham 2y ago
    I'm curious why you think JIT will not become necessary. My impression was that optimizing JIT compilers will basically always be multiple times faster than an interpreter.
    - aapoalas 2y ago
      I'm mostly just hoping it won't become necessary, though that is perhaps a vain hope. The reasoning is that, according to my interpretation of talking with some folks working on JSC and SM, property lookup inline caching is the most important performance optimisation bar none. JIT compiling is an improvement on top, definitely, but it is not an massive step change. Safari browser has a no-JIT mode that is fairly widely in use, and it is apparently fast enough that you don't really notice the change. Ladybird browser's LibJS has no JIT compiler, yet LibJS isn't really unbearably slow: The browser's biggest performance woes come from the browser around it and especially from having the simplest possible drawing algorithm possible. From a "personal" experience, while the test262 compliance test set is no performance benchmark, Nova is for some reason consistently at the very top of the runtime list over at https://test262.fyi/# https://test262.fyi/#. This is of course partially just because we're really quick to do a controlled panic if an unsupported code path is called, and the remaining part is because the code is run so little that JIT doesn't get to kick in. Still, this meaningless number gives me some measure of hope: We're consistently 3 times as fast as V8 after all :)
Permik 2y ago
Obligatory "Torille!" as a fellow Finn. Fun coincidence that you started this project, I've had this exact same idea brewing for a few years, but did not bite the bullet yet :D Have you considered using Bevy as a base ECS as they have an automatic archetype (shape) handling in the library? This was essentially my original idea, to implement a JS runtime on top of Bevy. (And over the years slap together a browser after the JS starts working)
- aapoalas 2y ago
  Torille! I have not considered Bevy, no. I sort of assumed that it wouldn't be easy to adapt to (thinking that it is more of a game engine), though it might've well been an excellent option. I _have_ thought about using Bevy as a rendering engine for some beautiful heap access animations. Imagine rows of little boxes, each row a heap vector and each box an item in it: The boxes blink as their memory is accessed. Oh what a sight it would be.
  - Permik 2y ago
    Yeah, Bevy is super, super modular and isn't really a game engine, it's just a general ECS framework that has lots of batteries made for it so you can make a game with it, but you don't have to. It's so gd versatile so people have done cool weird stuff with it: https://www.nikl.me/blog/2024/bevy_ecs_as_data_layer_in_leptos_ssg/ https://www.nikl.me/blog/2024/bevy_ecs_as_data_layer_in_lept...
PeterWhittaker 2y ago
Do you plan on supporting TCO? I was disappointed to learn a few years ago that V8 wouldn't, on the grounds that, IIRC, it would confuse developers. True tail call recursion and lazy evaluation would enable truly functional JS.
- aapoalas 2y ago
  It is the plans, since it is in the ECMAScript specification... It might actually be fairly easy now that I think about it?
  - eliassjogreen 2y ago
    If I am not mistaken there are a few `TODO`s sprinkled all over code relating to function calls about implementing TCO. Shouldn't be too hard from what I can remember when I last looked over those parts of the code.
dankobgd 2y ago
[flagged]
- aapoalas 2y ago
  There is a hidden agenda here: The engine is somewhat up to the gills with feature flags, and I'm planning on adding more. Say, for instance, array indexes being individually definable and the existence of holes? That whole can of worms makes JS Arrays a pain to implement in a performant fashion. Worse yet, it's a feature that is basically never used: No one wants holes in their Array and no one wants getters or setters in them either. So, say you have a nice flag to turn the feature off: You turn it off and test your code; nothing breaks and the engine thanks you by running faster. Nice! So you leave it off. A few years down the line you start to wonder: Why didn't we do this from the get go? And maybe, just maybe, this will push the ecosystem and the language itself towards sanity. We cannot break the Internet, but we sure as hell can break a bunch of old NPM libraries that no one uses anymore. Be the change you want to see, and all that. Though, if the change you want to see is for JavaScript to die then... Well, then this definitely isn't the revolution for you :D
- liontwist 2y ago
  Please share your plan for how to make millions of existing web pages better.
  - dankobgd 2y ago
    Why not make future pages better instead of old existing pages better? Why not improve the browsers or web assembly or dom or anything that hasn't changed in 20 years?
    - liontwist 2y ago
      > Why not make future pages better instead of old existing pages better? Existing pages already exist and people use them. Changing them puts the cost on thousands of other organizations over which you have no control, and likely very little influence.
ad-astra 2y ago
Wild, interested to see how Nova would perform on a benchmark suite.
- aapoalas 2y ago
  At the moment: Poorly! :D The biggest obstacle right now is that for any reasonably big benchmark, Nova will never finish as the GC cannot be run while JavaScript is running and in a big benchmark JS is always running. I've started a large-scale work to make the engine safe for interleaved garbage collection, but it's a ton of work and will take some time unfortunately. Once it is done, I will start doing benchmarks and seeing what takes time and where. From small-scale benchmarks I already know that our JS Value comparisons take too much time, our object property lookups are really expensive on larger objects (as it's a simple linear search), and our String interning is very slow (as it too is a dumb-as-rocks linear search).
ajith-joseph 2y ago
[dead]
- aapoalas 2y ago
  Thank you for your interest and fascination! To answer in brief: 1. We have async support but are still lacking some important parts (mainly interleaved GC) before complex, long-running performance benchmarks can be performed. I expect the performance to initially be relatively bad as we're missing important optimisations like shapes and inline caching. 2. The vector compacting is done so as to ensure that the heap allocated data does not fragment in memory. That being said, it's definitely possible that the heap vectors themselves slowly fragment to span disjoint memory areas instead of being all right next to each other. I don't think this will be a big problem though, as the vectors are still themselves densely packed. I expect the heap design will definitely suffer some penalties in cases where old data is slowly trickling out from underneath a mass of newer but still live data: During a major GC in these circumstances, the majority of data gets copied to densely pack the vector again. That being said, this isn't too different from a half-space copying garbage collector, and I don't think those are particularly terrible.
  - whizzter 2y ago
    I've built some prototypes and is there any particular reason you didn't go for NaN-tagged indexes instead unless it's for 32bit? Numeric cases would've had less loads since it's a number directly and indexes in the mantissa should be enough for at least about 48bit of ref space. I did consider a similar system ages ages ago for more easily embedding a JS engine into a C/C++ codebase, type-shapes would be allocated on a per page-basis so the runtime/GC wouldn't need any V-table pointers,etc on top of regular plain C object shapes to locate the type info but instead rely on an indirection per-page for those types shared with the C world. Ultimately felt a bit too complicated for something meant for embedding.
    - aapoalas 2y ago
      I didn't really consider NaN tagged indexes: Rust made using an enum basically a given. That being said, I probably wouldn't change even if could now. A NaN tagging scheme blocks out at least 11 bits out of your from your useful payload, leaving you with at most 46 bits to split between your discriminant and payload, while giving you freedom to express arbitrary doubles on the stack. A tagged index gives you 7 bytes to use for payload: This for instance gives us the possibility of representing all but the most decimal heavy doubles on the stack (we drop the bottom byte from a double if it is all zeroes, and save the remaining data on the stack), but also allowing up to 7 byte strings on the stack! And all safe integers! And up to 56 bits worth of Bigints! So, a tagged enum is pretty powerful :)
liontwist 2y ago
This is a great idea! I had thought about doing this with a lisp interpreter. I had identified a few key advantages: - homogenous allocation means no alignment gaps - linear access win in garbage collection - indices smaller than pointers - type discriminated index can save some size I haven’t verified whether those actually work out in the details. I’ll read your blog article. Don’t bother with these comments immediately comparing it to V8 (a multi billion dollar venture). I don’t know how many creative projects they’ve done before. You may be be interested in looking at Fabrice Bellard’s JS engine for ideas.
- aapoalas 2y ago
  Thank you for the encouragement! Avoiding alignment gaps is indeed pretty great: I have a vision of packing Arrays into 9 bytes split over two or three cache lines. On typed indexes: If we accept only about 2^24 possible index values then we could use a 32 bit integer for our Values, or at least for Objects (if we want to keep 7 bytes worth of stack data, which is pretty hard to pass on). I love the comments comparing Nova to V8: That's what I want to aim for after all :) I'm not sure I've heard of Fabrice Bellard's JS engine, thanks, I'll take a look!
  - NoahKAndrews 2y ago
    Your blog mentions QuickJS, which I believe is the mentioned engine by Fabrice
    - aapoalas 2y ago
      Oops :D
- mbrock 2y ago
  I actually made a Lisp interpreter in Zig a couple of years ago that has each object type in a separate heap array. In fact each field of each object type has its own array: every CDR is in one contiguous array. This was mostly for fun and to experiment with data-driven techniques using Zig metaprogramming. The code turned out relatively clean and simple. https://github.com/mbrock/wisp https://github.com/mbrock/wisp GC is stop&copy which as a side effect compacts each of those arrays and improves locality. I think most lists should end up having their CDRs next to each other in memory making iteration very cache friendly. But I didn't verify any performance qualities, beyond making it efficient enough for basic use. It also has delimited continuation control, compiles to WebAssembly, and hooks promises into the continuation system, among some other pretty cool features!
aag 2y ago
I recommend reading /Don’t Stop the BIBOP: Flexible and Efficient Storage Management for Dynamically Typed Languages/ (1994)[1]. "BIBOP" stands for "Big Bag of Pages." 1. https://legacy.cs.indiana.edu/~dyb/pubs/bibop.pdf https://legacy.cs.indiana.edu/~dyb/pubs/bibop.pdf
- aapoalas 2y ago
  Thank you, I'll put it on the reading list!
kccqzy 2y ago
What exactly is meant by the word "kind" here when you say kind-specific vectors? If I have `function X(a) { this.a = a; }` and then `function Y(b) { this.b = b; }` does that mean `new X(1)` and `new Y(2)` are considered objects of different kinds? And what about creating objects with literals: are `{a: 1}` and `{b: 2}` considered objects of different kinds?
- aapoalas 2y ago
  They're specification wise, statically separate kind of objects: A class constructor is special and requires more "internal slots" so they live in their own vector, as do ArrayBuffers, TypedArrays, Arrays, DataViews, Maps, Sets, ... But objects that have different shapes do not end up in their own vectors, since the shape is a dynamic property.
ianbicking 2y ago
I'm coming at this with no real JavaScript implementation knowledge, so these comments might not even make sense... The data sorting seems quite cleanly at first, but as I think more about it I don't quite get it. I guess you are saving a bit of space by segmenting by type... in another approach you might have the type on the pointer, and the pointer can point to anything, and so it's potentially a bit longer than having a type and pointer(/index) that points into a smaller portion of memory specific to that type. But enough to matter? "No, pointers we do not want and cannot have, so the only real option is to use indexes. Indexes have a lot of benefits: They are small, work exceedingly well together with our heap vectors, enable using the same value to index into multiple heap vectors (or slices of the same heap vector), perform a form of pointer compression automatically, and offer great protection from safety vulnerabilities as reinterpreting an index as a different type changes both the type and the memory it indexes into." That all just sounds like a pointer to me? The last case also seems like a security hole, not protection. "Not all objects are the same: They differ in their usage and their capabilities. An object-oriented reading of JavaScript objects' capabilities and the ECMAScript specification would give you a clear and simple inheritance graph where the ordinary object is the base object class, and Arrays, DataViews, Maps, and others inherit from that. Not all objects are the same: They differ in their usage and their capabilities. An object-oriented reading of JavaScript objects' capabilities and the ECMAScript specification would give you a clear and simple inheritance graph where the ordinary object is the base object class, and Arrays, DataViews, Maps, and others inherit from that." It seems like you are special-casing a specific set of object types (like Array), which is very justifiable. So sure. "This is somewhat more of an aim for the future instead of current reality, but allow me to give some easy examples: The ArrayBuffer object in ECMAScript supports allocating up to 2^53 bytes of data. Most engines only allow a tad bit over 2^32 bytes but nevertheless, the fact of the matter is that you need more than 4 bytes to store that byte value. As a result, ArrayBuffer itself but also DataView and all the various TypedArray variants like Uint8Array must carry within them 8 byte data fields for byte offset, byte length, and even array length. Now ask yourself, how often do you deal with ArrayBuffers larger than 4 GiB? Not very often, obviously." I'm guessing this is leading to a decision many languages have made about numbers and strings, where there's special types for small numbers and short strings (exposed only in the implementation). Or even more special types, where the pointers become values. Also I can see a benefit to keeping track of "normal" Arrays and whatnot, so some of JavaScripts weird-but-not-usually-used behavior can be isolated, and normal behavior fast-tracked. "In Nova we aim to split objects into parts to ensure that computationally unconnected parts are also stored separately in memory" But this I don't get. If you are splitting things by type, how can you cluster them by how they are related? An object like {a: 1, b: 2} is an object with two strings and two numbers, presumably spread out over three different type-specific heaps?
skybrian 2y ago
I’m wondering how this interacts with the “young objects mostly die” assumption of a generational garbage collector. It seems like using an arena for the young generation might work better for some programs, while an ECS-like scheme works better for other programs.
- aapoalas 2y ago
  Thank you for asking! I've not implemented and thus haven't proved this in action yet, but my thinking is that this interacts very well indeed: Each heap vector can designate an index that marks the beginning of the young generation. We don't need separate old and new spaces, instead promotion is just the act of moving the young generation beginning index up. Side note: I have a corollary on the "most objects die young" that is very much at the heart of Nova: Most objects live together. If they are created at the same time, then they're likely also used together. Hence why I don't swap items around in the heap vectors, or use a free list for allocation: It would mess up the temporal order of items in the vectors, leading to less chances at useful cache line sharing.
  - skybrian 2y ago
    Don’t you need to move the surviving young generation objects after the ones they’re surrounded by die? Otherwise the array is going to end up rather sparse, with a lot of unused array entries. Without either a free list or compaction, I don’t really see how you’re collecting garbage at all.
    - aapoalas 2y ago
      Yes, I do need to compact the young generation during GC. Eg. Let's say I have the young generation starting at index 1000 and I do GC with 1100 items, with 10 items surviving. I'll have to compact the remaining 10 items to the 1000..1010 span of the vector, after which I can also decide to promote the bottom two young generation indexes to the old generation, making the next young generation start index 1002.
throwawaymaths 2y ago
doesn't using these sorts of data structures turn the security safety properties of rust into silent logic errors?
- aapoalas 2y ago
  Nope. It rather explains the memory ownership of a JavaScript heap in a way that Rust understands: The heap owns all data in the heap, and JavaScript objects holding "references" to other objects do not imply memory ownership in the sense that Rust understands it. So, safery properties are not being silenced: The indexes definitely _are_ Rust wise unreliable where a pointer wouldn't be so bounds checks need to be done. But memory safety is not under threat here. This does mean that we have to take care of garbage collection ourselves, Rust will not do that for us, but that was the case anyhow since Rust doesn't have a garbage collector we could use (thank heavens). If we make mistakes here, it will lead to the JavaScript heap being corrupted from the JS code point of view but from the engine point of view the memory is still fully safe: The worst thing that can happen is a panic from out of bounds vector indexing.
  - int_19h 2y ago
    I think the point is that "memory safety", understood broadly, goes beyond that. You still have the notion of dangling pointers and such with indices, and while it doesn't allow for e.g. stack corruption, it still exposes many similar classes of bugs - for example, a "dangling" index to a deallocated object can potentially allow the code to read or write into a completely different object than it was originally pointing to. Hence, silent logic errors, potentially exploitable as well.
    - aapoalas 2y ago
      Yeah, sure in that sense this partially turns off Rust's safety features. That being said: A big part of making the engine be safe for interleaved GC is about using ZST's with lifetimes held inside them to bind any JavaScript Values when they appear on the stack and getting back parts of those security guarantees. We can still make mistakes, especially in the garbage collector, but that is again somewhat helped by code-sharing and coding conventions enabled by Rust ie. using destructuring in GC to make sure we don't forget any part of the heap data. (Coding conventions are not a solution, they are a mitigation at most. I _can_ write the heap GC as a map from one heap data of 'old lifetime to 'new, but that leads to worse code generation than mutating a 'static lifetime heap data :( )
ridiculous_fish 2y ago
"Numbers go into the numbers vector" is unusual - typically JS engines use either NaN-boxing or inline small integers (e.g. v8 SMI). I suppose this means that a simple `this.count += 1` will always allocate. Have you considered using NaN-boxing? Also, are the type-specific vectors compacted by the GC, or do they maintain a free list?
- aapoalas 2y ago
  We do have all safe integers inline (and most doubles too). I answered about NaN boxing somewhere here but basically, we get quite a bit of mileage from our tagged union / enum / ADT based Value, so I don't think I'd change to NaN boxing now even if I could.

271 points by aapoalas 2y ago

Etheryte 2y ago

Architectural choices are interesting to talk about, but I think most people reading this won't have any context to compare against, me included. How does this compare to e.g. the architecture of V8? What benefits do these choices give when compared against other engines? Etc, reading through the list it's easy to nod along, but it's hard to actually have an intuition about whether these are good choices or not.

aapoalas 2y ago
That's a good point. The "Internals of Nova" blog posts do a bit more explicit comparisons to V8. In V8, and other production engines AFAIK, objects are variable-sized monoliths: All of their statically known data is contained in one slab. This means that for example in Node.js an empty ArrayBuffer is 96 bytes in size (IIRC). Basically, they implement the ECMASCript specification defined inheritance chain using object-oriented class inheritance.
VPenkov 2y ago
They seem to have a blog post on that: https://trynova.dev/blog/why-build-a-js-engine https://trynova.dev/blog/why-build-a-js-engine It reads like an experimental approach because someone decided to will it into existence. That and to see if they can achieve better performance because of the architectural choices. > Luckily, we do have an idea, a new spin on the ECMAScript specification. The starting point is data-oriented design (...) > So, when you read a cache line you should aim for the entire cache line to be used. The best data structure in the world, bar none, is the humble vector (...) > So what we want to explore is then: What sort of an engine do you get when almost everything is a vector or an index into a vector, and data structures are optimised for cache line usage? Join us in finding out (...)
- aapoalas 2y ago
  The impetus for the engine design is indeed, as you say, "someone decided to will it into existence." A friend of mine who works in the gaming industry told me about the Entity Component System architecture and I thought: Hey, wouldn't that work for a JavaScript engine? So I decided to find out. Nova itself has already been created at that point and I was part of the project, but it was little more than a README. I then started to push it towards my vision, and the rest is not-quite-history.
  - kitd 2y ago
    A friend of mine who works in the gaming industry told me about the Entity Component System architecture and I thought: Hey, wouldn't that work for a JavaScript engine? That was the first thing I thought of when I saw your description. But the reason ECS works well is cache coherence. (Why) would a general-purpose runtime environment like a JS engine benefit from ECS? Or alternatively, have you seen performance improvements as a result?
    - aapoalas 2y ago
      I guess the opposite could also be asked: Why would a game benefit from ECS? A player in the game can do basically anything, there's no guarantee that things are always perfectly accessed in a linear order. It comes down to statistics: Large data sets in a general-purpose runtime environment are still created through parsing or looping, and they are consumed by looping. A human can manually create small data sets of entirely heterogenous data, but anything more than a 100 items is already unlikely. Finally, the garbage collector is a kind of "System" in the ECS sense. So even if the JavaScript code has managed to create very nonlinear data sets, the garbage collector will still enjoy benefits. (Tracing the data is still "pointer chasing" but when tracing we don't need to trace in the data order but can instead gather a collection of heap references we've seen, sort them in order and then trace them.)
fastball 2y ago
https://www.youtube.com/watch?v=5olgPdqKZ84 https://www.youtube.com/watch?v=5olgPdqKZ84

HatchedLake721 2y ago

[flagged]

aapoalas 2y ago
https://www.youtube.com/watch?v=-94qrgxH35M https://www.youtube.com/watch?v=-94qrgxH35M
- mdaniel 2y ago
  Absolutely perfect clapback, well done! o/

aapoalas 2y ago

A short comparison to how V8 does these things: 1. All data in V8 is allocated into one of many heap parts: Usually new data goes into a nursery space, and if it does not get GC'd it moves to the old space. Relative position of data isn't really guaranteed at this point. 2. All heap references in V8 are true pointers or, if pointer compression is used, offsets from the heap base. 3. All objects in V8 include all the data needed for them to act as objects, and all of their data is stored in a single allocation (with the exception of properties, with some exceptions). The more specialised an object is, say an ArrayBuffer, Uint8Array, or a DataView, the bigger it has to be as the specialisation requires more data to be stored.

pavlov 2y ago

Do you have some specific application profile in mind? Sounds like this approach could be useful for games that embed a scripting engine. In that context it might be interesting to eventually see some benchmarks against usual suspects of game scripting like Lua.

aapoalas 2y ago
The plan is to eventually get to full ECMAScript specification compatibility, and who knows if that would then bring us to eg. the Servo browser or Deno JS runtime. In the short term, I am interested in one-shot script running scenarios where only very limited JavaScript type are needed. The engine already has a bunch of feature flags that can be turned off to disable things like ArrayBuffers and other "complex" features. I have a work-related system in mind where only JSON based types are needed, and garbage collection isn't really necessary: The code could be run once and afterwards the system could be wiped down to the initial state and re-run. I also have half-a-mind to try running Nova on an STM32 board. But that could be called a hobby project within a hobby project :)

tobr 2y ago

Apologies for an insubstantial complaint, but there are just too many things called “Nova” (or its Greek counterpart, “Neo”). I get it, it’s new, but isn’t there anything more specific or unique to reflect in the project name?

aapoalas 2y ago
Heh, no apology needed. It's definitely an overused name. We bikeshed the name a good few years ago and came to "Nova" from "Supernova" because space is, like, cool. Rebranding would feel weird now :) I console myself with the knowledge that most engine names are unknown anyway, and even if known they are still unsearchable (looking at you two, V8 and JSC!)
deleted 2y ago
[deleted]
load1n9 2y ago
Absolutely overused but allows for cool puns

gardaani 2y ago

Is this an experimental only JS engine or do you aim to implement the entire ECMAscript specification? I have been following the Rust Boa project, but I think that it isn't production ready, yet. https://github.com/boa-dev/boa https://github.com/boa-dev/boa

aapoalas 2y ago
The aim is absolutely to implement the entire ECMAScript specification. Progress has slowed down recently, as I've been both busy with other things and tied up in making the engine work with interleaved GC. A secondary aim is to have a bunch of feature flags that allows the engine to drop out support for specification parts that a particular embedder doesn't care about. That obviously fights with the "implement the entire ECMAScript specification" goal, but I just hate indexed property getters and setters with a passion and want to see them gone wherever I go. Boa is a great project and I believe it is being used in some production systems. I've met and exchanged some ideas with the main developer, Jason Williams, and even received the greatest praise that I could imagine: Boa will (or did?) take some inspiration from Nova on its GC refactoring. Nova has also copied (with proper attribution of course) a few minor parts from Boa, like whitespace skipping code for some spec abstract operations. I highly recommend keeping an eye out and using Boa if you have the chance.

lionkor 2y ago

Isn't data oriented design driven by knowing what your data accesses look like? In your engine, you're building as if you're assuming that common data access will be linear access over objects of the same type. Why?

aapoalas 2y ago
Yeah, know your data and how it is used. I assume that data access is mostly linear because of a few reasons: 1. All performance issues arise in loops: I at least have never seen a performance problem that could be explained by a single thing happening once. It is always a particular thing happening over and over again. 2. All loops deal with collections of data, and the collections are usually created either created manually by a human being, or are created through parsing or looping many at a time. 3. A human being can manually create a collection of maybe a hundred items manually before they get bored and stop. A collection created this way may contain data from all over the place, with data access over it being nonlinear. 4. A collection created through parsing or looping will create its data in a mostly linear fashion. Accessing the data will then also be linear. There are definitely cases where nonlinear collections exist, but these are usually either small or are created from smaller sets of linear data. eg. Think of dragging 10 lists of 1000 items to form a list of 10000 items. The entire 10000 items aren't going to be located linearly, but every 1000 items will be. So in effect, I'm betting that most hot loops do deal with linear access over objects and that loops that work over nonlinear access are not particularly hot.
- lionkor 2y ago
  Makes sense when you put it like that, thanks very much for explaining your thought process.

ksec 2y ago

Well, Devs of V8, Spidermonkey, Webkit and GraalJS are all on HN. Hopefully they see this and all chime in.

aapoalas 2y ago
I hope so too :) I've contributed some minor bits of code to V8 and then worked on Nova for a year or two, but I'm still wet behind the ears compared to those folks. Any and all comments I can get from them is a blessing.

pansa2 2y ago

Does Nova include a JIT compiler? Or just an interpreter?

aapoalas 2y ago
Nova only has a bytecode compiler and interpreter. I do not plan on trying my hand at JIT compiling any time in the future. In this I am a follower of Ladybird's Andreas Kling and hope that JIT will not become necessary.
- mightyham 2y ago
  I'm curious why you think JIT will not become necessary. My impression was that optimizing JIT compilers will basically always be multiple times faster than an interpreter.
  - aapoalas 2y ago
    I'm mostly just hoping it won't become necessary, though that is perhaps a vain hope. The reasoning is that, according to my interpretation of talking with some folks working on JSC and SM, property lookup inline caching is the most important performance optimisation bar none. JIT compiling is an improvement on top, definitely, but it is not an massive step change. Safari browser has a no-JIT mode that is fairly widely in use, and it is apparently fast enough that you don't really notice the change. Ladybird browser's LibJS has no JIT compiler, yet LibJS isn't really unbearably slow: The browser's biggest performance woes come from the browser around it and especially from having the simplest possible drawing algorithm possible. From a "personal" experience, while the test262 compliance test set is no performance benchmark, Nova is for some reason consistently at the very top of the runtime list over at https://test262.fyi/# https://test262.fyi/#. This is of course partially just because we're really quick to do a controlled panic if an unsupported code path is called, and the remaining part is because the code is run so little that JIT doesn't get to kick in. Still, this meaningless number gives me some measure of hope: We're consistently 3 times as fast as V8 after all :)

Permik 2y ago

Obligatory "Torille!" as a fellow Finn. Fun coincidence that you started this project, I've had this exact same idea brewing for a few years, but did not bite the bullet yet :D Have you considered using Bevy as a base ECS as they have an automatic archetype (shape) handling in the library? This was essentially my original idea, to implement a JS runtime on top of Bevy. (And over the years slap together a browser after the JS starts working)

aapoalas 2y ago
Torille! I have not considered Bevy, no. I sort of assumed that it wouldn't be easy to adapt to (thinking that it is more of a game engine), though it might've well been an excellent option. I _have_ thought about using Bevy as a rendering engine for some beautiful heap access animations. Imagine rows of little boxes, each row a heap vector and each box an item in it: The boxes blink as their memory is accessed. Oh what a sight it would be.
- Permik 2y ago
  Yeah, Bevy is super, super modular and isn't really a game engine, it's just a general ECS framework that has lots of batteries made for it so you can make a game with it, but you don't have to. It's so gd versatile so people have done cool weird stuff with it: https://www.nikl.me/blog/2024/bevy_ecs_as_data_layer_in_leptos_ssg/ https://www.nikl.me/blog/2024/bevy_ecs_as_data_layer_in_lept...

PeterWhittaker 2y ago

Do you plan on supporting TCO? I was disappointed to learn a few years ago that V8 wouldn't, on the grounds that, IIRC, it would confuse developers. True tail call recursion and lazy evaluation would enable truly functional JS.

aapoalas 2y ago
It is the plans, since it is in the ECMAScript specification... It might actually be fairly easy now that I think about it?
- eliassjogreen 2y ago
  If I am not mistaken there are a few `TODO`s sprinkled all over code relating to function calls about implementing TCO. Shouldn't be too hard from what I can remember when I last looked over those parts of the code.

dankobgd 2y ago

[flagged]

aapoalas 2y ago
There is a hidden agenda here: The engine is somewhat up to the gills with feature flags, and I'm planning on adding more. Say, for instance, array indexes being individually definable and the existence of holes? That whole can of worms makes JS Arrays a pain to implement in a performant fashion. Worse yet, it's a feature that is basically never used: No one wants holes in their Array and no one wants getters or setters in them either. So, say you have a nice flag to turn the feature off: You turn it off and test your code; nothing breaks and the engine thanks you by running faster. Nice! So you leave it off. A few years down the line you start to wonder: Why didn't we do this from the get go? And maybe, just maybe, this will push the ecosystem and the language itself towards sanity. We cannot break the Internet, but we sure as hell can break a bunch of old NPM libraries that no one uses anymore. Be the change you want to see, and all that. Though, if the change you want to see is for JavaScript to die then... Well, then this definitely isn't the revolution for you :D
liontwist 2y ago
Please share your plan for how to make millions of existing web pages better.
- dankobgd 2y ago
  Why not make future pages better instead of old existing pages better? Why not improve the browsers or web assembly or dom or anything that hasn't changed in 20 years?
  - liontwist 2y ago
    > Why not make future pages better instead of old existing pages better? Existing pages already exist and people use them. Changing them puts the cost on thousands of other organizations over which you have no control, and likely very little influence.

ad-astra 2y ago

Wild, interested to see how Nova would perform on a benchmark suite.

aapoalas 2y ago
At the moment: Poorly! :D The biggest obstacle right now is that for any reasonably big benchmark, Nova will never finish as the GC cannot be run while JavaScript is running and in a big benchmark JS is always running. I've started a large-scale work to make the engine safe for interleaved garbage collection, but it's a ton of work and will take some time unfortunately. Once it is done, I will start doing benchmarks and seeing what takes time and where. From small-scale benchmarks I already know that our JS Value comparisons take too much time, our object property lookups are really expensive on larger objects (as it's a simple linear search), and our String interning is very slow (as it too is a dumb-as-rocks linear search).

ajith-joseph 2y ago

[dead]

aapoalas 2y ago
Thank you for your interest and fascination! To answer in brief: 1. We have async support but are still lacking some important parts (mainly interleaved GC) before complex, long-running performance benchmarks can be performed. I expect the performance to initially be relatively bad as we're missing important optimisations like shapes and inline caching. 2. The vector compacting is done so as to ensure that the heap allocated data does not fragment in memory. That being said, it's definitely possible that the heap vectors themselves slowly fragment to span disjoint memory areas instead of being all right next to each other. I don't think this will be a big problem though, as the vectors are still themselves densely packed. I expect the heap design will definitely suffer some penalties in cases where old data is slowly trickling out from underneath a mass of newer but still live data: During a major GC in these circumstances, the majority of data gets copied to densely pack the vector again. That being said, this isn't too different from a half-space copying garbage collector, and I don't think those are particularly terrible.
- whizzter 2y ago
  I've built some prototypes and is there any particular reason you didn't go for NaN-tagged indexes instead unless it's for 32bit? Numeric cases would've had less loads since it's a number directly and indexes in the mantissa should be enough for at least about 48bit of ref space. I did consider a similar system ages ages ago for more easily embedding a JS engine into a C/C++ codebase, type-shapes would be allocated on a per page-basis so the runtime/GC wouldn't need any V-table pointers,etc on top of regular plain C object shapes to locate the type info but instead rely on an indirection per-page for those types shared with the C world. Ultimately felt a bit too complicated for something meant for embedding.
  - aapoalas 2y ago
    I didn't really consider NaN tagged indexes: Rust made using an enum basically a given. That being said, I probably wouldn't change even if could now. A NaN tagging scheme blocks out at least 11 bits out of your from your useful payload, leaving you with at most 46 bits to split between your discriminant and payload, while giving you freedom to express arbitrary doubles on the stack. A tagged index gives you 7 bytes to use for payload: This for instance gives us the possibility of representing all but the most decimal heavy doubles on the stack (we drop the bottom byte from a double if it is all zeroes, and save the remaining data on the stack), but also allowing up to 7 byte strings on the stack! And all safe integers! And up to 56 bits worth of Bigints! So, a tagged enum is pretty powerful :)

liontwist 2y ago

This is a great idea! I had thought about doing this with a lisp interpreter. I had identified a few key advantages: - homogenous allocation means no alignment gaps - linear access win in garbage collection - indices smaller than pointers - type discriminated index can save some size I haven’t verified whether those actually work out in the details. I’ll read your blog article. Don’t bother with these comments immediately comparing it to V8 (a multi billion dollar venture). I don’t know how many creative projects they’ve done before. You may be be interested in looking at Fabrice Bellard’s JS engine for ideas.

aapoalas 2y ago
Thank you for the encouragement! Avoiding alignment gaps is indeed pretty great: I have a vision of packing Arrays into 9 bytes split over two or three cache lines. On typed indexes: If we accept only about 2^24 possible index values then we could use a 32 bit integer for our Values, or at least for Objects (if we want to keep 7 bytes worth of stack data, which is pretty hard to pass on). I love the comments comparing Nova to V8: That's what I want to aim for after all :) I'm not sure I've heard of Fabrice Bellard's JS engine, thanks, I'll take a look!
- NoahKAndrews 2y ago
  Your blog mentions QuickJS, which I believe is the mentioned engine by Fabrice
  - aapoalas 2y ago
    Oops :D
mbrock 2y ago
I actually made a Lisp interpreter in Zig a couple of years ago that has each object type in a separate heap array. In fact each field of each object type has its own array: every CDR is in one contiguous array. This was mostly for fun and to experiment with data-driven techniques using Zig metaprogramming. The code turned out relatively clean and simple. https://github.com/mbrock/wisp https://github.com/mbrock/wisp GC is stop&copy which as a side effect compacts each of those arrays and improves locality. I think most lists should end up having their CDRs next to each other in memory making iteration very cache friendly. But I didn't verify any performance qualities, beyond making it efficient enough for basic use. It also has delimited continuation control, compiles to WebAssembly, and hooks promises into the continuation system, among some other pretty cool features!

aag 2y ago

I recommend reading /Don’t Stop the BIBOP: Flexible and Efficient Storage Management for Dynamically Typed Languages/ (1994)[1]. "BIBOP" stands for "Big Bag of Pages." 1. https://legacy.cs.indiana.edu/~dyb/pubs/bibop.pdf https://legacy.cs.indiana.edu/~dyb/pubs/bibop.pdf

aapoalas 2y ago
Thank you, I'll put it on the reading list!

kccqzy 2y ago

What exactly is meant by the word "kind" here when you say kind-specific vectors? If I have `function X(a) { this.a = a; }` and then `function Y(b) { this.b = b; }` does that mean `new X(1)` and `new Y(2)` are considered objects of different kinds? And what about creating objects with literals: are `{a: 1}` and `{b: 2}` considered objects of different kinds?

aapoalas 2y ago
They're specification wise, statically separate kind of objects: A class constructor is special and requires more "internal slots" so they live in their own vector, as do ArrayBuffers, TypedArrays, Arrays, DataViews, Maps, Sets, ... But objects that have different shapes do not end up in their own vectors, since the shape is a dynamic property.

ianbicking 2y ago

I'm coming at this with no real JavaScript implementation knowledge, so these comments might not even make sense... The data sorting seems quite cleanly at first, but as I think more about it I don't quite get it. I guess you are saving a bit of space by segmenting by type... in another approach you might have the type on the pointer, and the pointer can point to anything, and so it's potentially a bit longer than having a type and pointer(/index) that points into a smaller portion of memory specific to that type. But enough to matter? "No, pointers we do not want and cannot have, so the only real option is to use indexes. Indexes have a lot of benefits: They are small, work exceedingly well together with our heap vectors, enable using the same value to index into multiple heap vectors (or slices of the same heap vector), perform a form of pointer compression automatically, and offer great protection from safety vulnerabilities as reinterpreting an index as a different type changes both the type and the memory it indexes into." That all just sounds like a pointer to me? The last case also seems like a security hole, not protection. "Not all objects are the same: They differ in their usage and their capabilities. An object-oriented reading of JavaScript objects' capabilities and the ECMAScript specification would give you a clear and simple inheritance graph where the ordinary object is the base object class, and Arrays, DataViews, Maps, and others inherit from that. Not all objects are the same: They differ in their usage and their capabilities. An object-oriented reading of JavaScript objects' capabilities and the ECMAScript specification would give you a clear and simple inheritance graph where the ordinary object is the base object class, and Arrays, DataViews, Maps, and others inherit from that." It seems like you are special-casing a specific set of object types (like Array), which is very justifiable. So sure. "This is somewhat more of an aim for the future instead of current reality, but allow me to give some easy examples: The ArrayBuffer object in ECMAScript supports allocating up to 2^53 bytes of data. Most engines only allow a tad bit over 2^32 bytes but nevertheless, the fact of the matter is that you need more than 4 bytes to store that byte value. As a result, ArrayBuffer itself but also DataView and all the various TypedArray variants like Uint8Array must carry within them 8 byte data fields for byte offset, byte length, and even array length. Now ask yourself, how often do you deal with ArrayBuffers larger than 4 GiB? Not very often, obviously." I'm guessing this is leading to a decision many languages have made about numbers and strings, where there's special types for small numbers and short strings (exposed only in the implementation). Or even more special types, where the pointers become values. Also I can see a benefit to keeping track of "normal" Arrays and whatnot, so some of JavaScripts weird-but-not-usually-used behavior can be isolated, and normal behavior fast-tracked. "In Nova we aim to split objects into parts to ensure that computationally unconnected parts are also stored separately in memory" But this I don't get. If you are splitting things by type, how can you cluster them by how they are related? An object like {a: 1, b: 2} is an object with two strings and two numbers, presumably spread out over three different type-specific heaps?

skybrian 2y ago

I’m wondering how this interacts with the “young objects mostly die” assumption of a generational garbage collector. It seems like using an arena for the young generation might work better for some programs, while an ECS-like scheme works better for other programs.

aapoalas 2y ago
Thank you for asking! I've not implemented and thus haven't proved this in action yet, but my thinking is that this interacts very well indeed: Each heap vector can designate an index that marks the beginning of the young generation. We don't need separate old and new spaces, instead promotion is just the act of moving the young generation beginning index up. Side note: I have a corollary on the "most objects die young" that is very much at the heart of Nova: Most objects live together. If they are created at the same time, then they're likely also used together. Hence why I don't swap items around in the heap vectors, or use a free list for allocation: It would mess up the temporal order of items in the vectors, leading to less chances at useful cache line sharing.
- skybrian 2y ago
  Don’t you need to move the surviving young generation objects after the ones they’re surrounded by die? Otherwise the array is going to end up rather sparse, with a lot of unused array entries. Without either a free list or compaction, I don’t really see how you’re collecting garbage at all.
  - aapoalas 2y ago
    Yes, I do need to compact the young generation during GC. Eg. Let's say I have the young generation starting at index 1000 and I do GC with 1100 items, with 10 items surviving. I'll have to compact the remaining 10 items to the 1000..1010 span of the vector, after which I can also decide to promote the bottom two young generation indexes to the old generation, making the next young generation start index 1002.

throwawaymaths 2y ago

doesn't using these sorts of data structures turn the security safety properties of rust into silent logic errors?

aapoalas 2y ago
Nope. It rather explains the memory ownership of a JavaScript heap in a way that Rust understands: The heap owns all data in the heap, and JavaScript objects holding "references" to other objects do not imply memory ownership in the sense that Rust understands it. So, safery properties are not being silenced: The indexes definitely _are_ Rust wise unreliable where a pointer wouldn't be so bounds checks need to be done. But memory safety is not under threat here. This does mean that we have to take care of garbage collection ourselves, Rust will not do that for us, but that was the case anyhow since Rust doesn't have a garbage collector we could use (thank heavens). If we make mistakes here, it will lead to the JavaScript heap being corrupted from the JS code point of view but from the engine point of view the memory is still fully safe: The worst thing that can happen is a panic from out of bounds vector indexing.
- int_19h 2y ago
  I think the point is that "memory safety", understood broadly, goes beyond that. You still have the notion of dangling pointers and such with indices, and while it doesn't allow for e.g. stack corruption, it still exposes many similar classes of bugs - for example, a "dangling" index to a deallocated object can potentially allow the code to read or write into a completely different object than it was originally pointing to. Hence, silent logic errors, potentially exploitable as well.
  - aapoalas 2y ago
    Yeah, sure in that sense this partially turns off Rust's safety features. That being said: A big part of making the engine be safe for interleaved GC is about using ZST's with lifetimes held inside them to bind any JavaScript Values when they appear on the stack and getting back parts of those security guarantees. We can still make mistakes, especially in the garbage collector, but that is again somewhat helped by code-sharing and coding conventions enabled by Rust ie. using destructuring in GC to make sure we don't forget any part of the heap data. (Coding conventions are not a solution, they are a mitigation at most. I _can_ write the heap GC as a map from one heap data of 'old lifetime to 'new, but that leads to worse code generation than mutating a 'static lifetime heap data :( )

ridiculous_fish 2y ago

"Numbers go into the numbers vector" is unusual - typically JS engines use either NaN-boxing or inline small integers (e.g. v8 SMI). I suppose this means that a simple `this.count += 1` will always allocate. Have you considered using NaN-boxing? Also, are the type-specific vectors compacted by the GC, or do they maintain a free list?

aapoalas 2y ago
We do have all safe integers inline (and most doubles too). I answered about NaN boxing somewhere here but basically, we get quite a bit of mileage from our tagged union / enum / ADT based Value, so I don't think I'd change to NaN boxing now even if I could.