[andai]

This is cool, but I'm wondering

(1) Why doesn't V8, whose whole point is performance, lay out memory in an optimal way?

(2) Will Nova need to also implement all of V8's other optimizations, to see if Nova's layout makes any significant difference?

[aapoalas]

V8 could probably implement the backing object "trick" with some trouble. I'm half-hoping that Nova will show it to be worth their while and that they will eventually do it. It will be a major refactoring of the engine, however.

The heap vector "trick" is basically impossible, I believe. It wouldn't be a refactoring so much as it would be a complete rewrite of the engine. The entirety of V8 assumes it deals in pointers, and all of that would need to change to using indexes instead. I will eat my hat if they do it. Without heap vectors they can still split object data apart using pointer-keyed hash maps, so maybe they could take advantage of some of the ideas still.

V8 does offer ways to run code without optimisations, which we can use for a more apples-to-apples comparison. The most important optimisation that Nova really needs before any big performance comparisons become meaningful is property access inline caching, which requires implementing object shapes.

I'd say that once object shapes are done, then limited performance comparisons can probably be made, especially if V8's JIT is disabled.

[Leszek]

To be fair, pointer compression is morally and memory-wise similar to indexing a vector.

[aapoalas]

Yup, and to a degree the whole "heap references as indexes" idea was inspired by pointer compression. Not in a direct sense of "hey, look at that, what if I took it a step further?" but as I was thinking of the indexes I realised that it looks a lot like pointer compression, and that made me think it is a viable idea.

[reverius42]

So is the whole point of this project to convince V8 to adopt a particular optimization?

[aapoalas]

Not really: In my daydreams Nova becomes the premier JS engine in the world and takes the crown from V8. If V8 went all in and basically just copied all of Nova... I'd probably still develop Nova, as I don't want to work with C++ that much.

If V8 copied all of Nova AND adopted Rust, I might consider laying Nova to rest and going into V8 development. But I'd probably also be really angry at V8 just taking all of Nova's good ideas and peddling them off as their own without crediting Nova. So probably I'd still keep developing Nova while stewing in my anger and inability to do anything about it :)

I hope Nova can be a spark that ignites the JavaScript world into a bit of a renaissance with some of its ideas, but the point is not to burn bright and burn out. The point is to burn bright and stay lit.

[rob74]

> But I'd probably also be really angry at V8 just taking all of Nova's good ideas and peddling them off as their own without crediting Nova.

Who knows, maybe they'd even give you credit (while still taking the idea)?

[aapoalas]

It could definitely happen. It would be a hard decision for me then :)

[munificent]

Optimal memory layout isn't something you can know in advance. The optimal way to lay out objects in memory is exactly in the order that they will be accessed, but the runtime doesn't know that until after the user program has accessed them.

And if the program accesses a set of objects in different orders at different times, there is no one optimal layout.

I did ask Lars Bak once if they spent a lot of time thinking about cache usage and organizing objects in memory to take best advantage of it and, if I recall correctly, his answer was basically "no". They definitely think about it terms of packing objects into small amounts of memory. But in a dynamically typed language like JavaScript where every property is a reference to some other object elsewhere in memory, using the cache well is just profoundly hard.

Hell, it's hard even in Java where at least you do know the set of fields any given class has.

[liontwist]

1 it takes time and effort to make major architectural changes.

Certain design choices made for other reasons may conflict.