> 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.
I don't understand. Why do you need nodes that are not proxies? What would they be instead? If some of them are not proxies, then you'll need to make sure that the properties are added to the non-proxy objects in the right order every time. And they'd all have to be allocated with the same number of inline slots. But I guess it could be done. > > 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. I'm not sure I understand this. Are 16 inline slots enough, or will you need to use dynamic slots? It would be much easier to avoid dynamic slots. If you need dynamic slots, then maybe we could work out a special deal where proxies allocate all their dynamic slots up front, when they're created. That way the layout would always be the same and you wouldn't have to worry about realloc-ing the slots. > > 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 think we definitely would want to avoid ever changing the dynamic slots pointer if there is one. We could do so by preallocating the dynamic slots, as above. > > 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? I guess if you want to use non-proxy objects then we'd have to worry about a memory fence. If you need dynamic slots, it seems like we'd need them for proxies and non-proxies, since I thought the layout needs to be the same for everything. Sorry if this is a little disjointed. I still don't understand all the requirements. Also, a lot of the problems you're bringing up now would still exist even if each proxy handler had its own class. -Bill _______________________________________________ dev-tech-js-engine-internals mailing list [email protected] https://lists.mozilla.org/listinfo/dev-tech-js-engine-internals
