1,569 karma · joined May 2, 2012
I'd add that the claim that this could be implemented in V8 doesn't take into account pointer compression, where on-heap V8 tagged pointers are 32-bit, not 64-bit.
The article does mention that there was a "high degree of agreement with the expert physicians in their grading", but it's nevertheless sad how much the report focuses on time spent on the task, and not on the correctness of the results, especially when it concerns a medical diagnosis. Very much inline with my expectations for a report on "AI for X".
The biggest difference between the two is that JS objects are fully managed by the GC and V8 has full control over their layout and access (e.g. they are accessed via explicit pointer + field offset in the runtime), while Oilpan works on C++ objects; there's a billion consequences of this, in particular that JS objects are movable (because we can safely update pointers) and Oilpan objects aren't (because C++ can do pretty much whatever it wants).
There's actually lots of really interesting consequences of the current implementation, and the various tricks it does around what's observable and what's fast, it's just not what's described here.
Yes, please avoid leaking memory -- but the intro to this article is incorrect in almost all major points:
> In JavaScript, primitives are assigned/passed by value and not by reference. If you assign a primitive type's value to another variable, the value is copied.
No, primitives are immutable but still passed by reference (that reference is passed by value, which is why assigning to the reference won't change them -- the same is true for objects). Can you imagine if we'd copied strings every time they were passed into a function?
> This also determines how they are stored in memory — primitive values are stored on the stack while objects are stored on the heap, with a reference to their location stored on the stack.
Also no, all primitives except small integers ("Smis") are stored in the heap.
> One important thing to note about variables stored in the stack is that their sizes must be known at compile time. This allows a program to allocate the right amount of memory in the stack. Because the JavaScript engine allocates a fixed amount of memory for primitive values, there is a limit to how large they can be.
Again, no, with strings as the obvious counter example. There's a limit to how large values in general can be, but it's around indexable size and pointer width, not a fixed amount of memory for primitives.
> Memory stored in the heap will live on unless it is explicitly deleted or deallocated.
Is the author confusing the malloc heap with the (garbage collected) JS heap? Sure, V8 has to manage the pages it allocates, but JS authors certainly don't
> To allocate memory in the heap, a program must first scan the heap to find a contiguous memory block large enough to hold the data.
As a sibling comment points out, there are optimisations here with linear allocation buffers that permit bump allocation. Also, don't forget the semi space for young objects, since the GC is generational.
But, the V8 one is very similar in many respects (the same team works on both), including linear allocation buffers.