Boris said: > I think the idea is to try to have objects that are allocated in the JS > heap but that are treated as Rust objects from Rust. That means that > the actual object layout needs to be the same for all Node objects, say > (if the Node members are stored in the JS-heap allocation).
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. 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. > > Then you could just use getSlot and setSlot on them. > > 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. I don't think the shape ever changes for a proxy object, since proxies are non-native. Therefore, I think you should be fine doing this. If we do end up giving a new shape to a proxy for some reason (maybe to change the parent or something crazy like that) then we'd need a memory fence when writing in the new shape, I guess. -Bill _______________________________________________ dev-tech-js-engine-internals mailing list [email protected] https://lists.mozilla.org/listinfo/dev-tech-js-engine-internals
