On 7/18/13 11:45 PM, Bill McCloskey wrote:
Well, these wouldn't be normal properties. There wouldn't be shapes for them or
anything. You would still access them using slot numbers that you would have to
lay out yourself. So I don't think there would be any issues with different
objects having different layouts.
Well, except that some nodes are proxies and some are not.
One issue that comes to mind is that you would only have as many slots as are
stored inline in the object. Right now that's a maximum of 16. We might be able
to add the ability to malloc slot arrays if you need more, but that's not there
now. And I'm guessing you would always want inline slots anyway.
Right; the current servo DOM thinking seems to be that the members that
are in the superclasses and fit in slots go in slots, and the rest go in
a Rust-side heap allocation of some sort.
Mmm.... Can the JS engine deal with getSlot from the layout thread on a
non-reserved slot that the firstChild pointer is stored in, say, while
properties are being added to the object on the main thread?
The only thing getSlot looks at is the number of fixed slots, which is stored
in the shape.
And then the dynamic slot pointer if you don't fit in the fixed slots,
which can change when you add properties, afaict, right.
I don't think the shape ever changes for a proxy object
Yes, but not all our objects are proxies... I guess we'd only be using
dynamic slots for the proxies, is the proposal?
-Boris
_______________________________________________
dev-tech-js-engine-internals mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-tech-js-engine-internals
