aapoalas

10 ms·

91.
by aapoalas 2y ago
Thank you for the discussion! A few gaps won't matter, and that to me speaks of a split between major and minor GC making sense. However, I'm not really sold on that meaning a free list making sense. For one, if I split the heap v
92.
by 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 cha
93.
by aapoalas 2y ago
That is definitely possible: If it turns out to not make sense then I can at least always go back go the current system where all properties of an object as stored in a single array. It's not as ECS'ssy as one would hope but it&#x
94.
by aapoalas 2y ago
Ah, of course!
95.
by 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 Valu
96.
by aapoalas 2y ago
Yeah, I'm quite envious of the MultiArrayList or whatever it was that Zig has: If only Rust had that sort of a type built-in <3
97.
by aapoalas 2y ago
Well I'll be damned! That sounds very much like what I want Nova to eventually be :) We don't have fields split apart at present, mostly because Rust doesn't make that quite as easy as I would want to. Otherwise it sounds lik
98.
by 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 t
99.
by 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 10
100.
by 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 generati
101.
by aapoalas 2y ago
Excellent question: In a theoretical sense the answer would be that we cannot know since it depends on the JavaScript being run. But: In practice I think that is indeed the case. Especially for the more common an object is, the likelier it
102.
by aapoalas 2y ago
Oops :D
103.
by aapoalas 2y ago
Hey, thank you for the comment! I'll try to answer as best I can. A pointer is 64 bits, though carrying much less useful payload than that. A JavaScript engine only rarely deals with more than 4 GiB of memory, so a 32 bit integer would
104.
by 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, Se
105.
by aapoalas 2y ago
I would have to keep a free list per vector, and there's a lot of those, and it would defeat the point of keeping data packed and temporally colocated: I want to ensure that data was created together stays together and only ever gets m
106.
by aapoalas 2y ago
That would be one way; it would offer the best theoretical memory layout for well-behaved programs. But, I expect it to be very painful to work with and to come with some performance penalties in mixed use cases due to the extra indirection
107.
by aapoalas 2y ago
Thank you, I'll put it on the reading list!
108.
by 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 p
109.
by 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 w
110.
by 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
111.
by 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 l
112.
by 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 worm
113.
by 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?
114.
by 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
115.
by aapoalas 2y ago
Yeah, virtual alloc for the Vec backing memory is something I hope to do _one day_. It's not a very pressing concern however, as it requires going much lower in the stack.
116.
by aapoalas 2y ago
Thank you very much for your well-wishes <3 > Yes, but note this is still a different pattern of access (array of "entities"). I was referring to the `[foo, foo2, foo3]` objects themselves; V8 does use an "cache local&q
117.
by aapoalas 2y ago
It is very true that a general purpose computation can theoretically do anything and mess linearity of access patterns entirely up. But in practice programs do most of their work in very linear fashion. It's not by chance that eg. V8 w
118.
by 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 mo
119.
by aapoalas 2y ago
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
120.
by 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.

More ›