3 ms·
Huh, no types. So every field is 8 bytes I guess? I suppose if you want a defined/packed memory layout you can already use SharedArrayBuffer and if you want to
by modeless 2y ago
Huh, no types. So every field is 8 bytes I guess?
I suppose if you want a defined/packed memory layout you can already use SharedArrayBuffer and if you want to store objects in it you can use this BufferBackedObjects library they linked. https://github.com/GoogleChromeLabs/buffer-backed-object https://github.com/GoogleChromeLabs/buffer-backed-object
I also expect that in browsers this will have the same cross-origin isolation requirements as SharedArrayBuffer that make it difficult to use.
- syg 2y agoTo be more precise, aligned to whatever size such that you can guarantee field writes that don't tear. Pointer-aligned is a safe bet. 4-byte aligned should be okay too on 64bit architectures if you use pointer compression like V8 does. What kind of types did you have in mind? Machine integers and "any" (i.e., a JS primitive or object)? And yes, in browsers this will be gated by cross-origin isolation.
- modeless 2y agoIf the memory layout is fixed and fields are untyped then every field must be at least 8 bytes to potentially hold a double precision floating point value. There would clearly be value in adding typing to restrict field values to 1 or 2 or 4 byte integers to allow packing those fields. But I can see that it would add complexity.
- syg 2y agoOnly if your implementation holds doubles without boxing them. V8 boxes doubles, but JSC and SpiderMonkey do not.