←back to thread

269 points aapoalas | 3 comments | | HN request time: 0.6s | source

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

1. PeterWhittaker ◴[] No.42172266[source]
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.

replies(1): >>42172436 #
2. aapoalas ◴[] No.42172436[source]
It is the plans, since it is in the ECMAScript specification... It might actually be fairly easy now that I think about it?
replies(1): >>42174151 #
3. eliassjogreen ◴[] No.42174151[source]
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.