On 07/18/2013 01:46 PM, Josh Matthews wrote:
I'm experimenting with storing Servo DOM objects in the reserved slots of
the JS wrappers, but hitting a wall when it comes to DOM proxy objects.
Since we can't modify the number of reserved slots for a given proxy class,
Boris came up with a proposal to make this possible:
[16:06:31] <bz> So here's my proposal
[16:06:44] <bz> 1) Create a new subclass of JSClass, call it ProxyClass
[16:06:58] <bz> 2) Make SpiderMonkey proxies use that as their JSClass
[16:07:21] <bz> hmmm
[16:07:26] * bz thinks
[16:07:43] <bz> Basically, I'd like to move the handler out of the reserved
slot.
[16:08:07] <bz> Replace checks for &ProxyObjectClass with some sort of flag
check
[16:08:17] <bz> have different kinds of proxies have different JSClass
pointers
[16:08:21] <bz> and store the handler in the JSClass
[16:08:28] <bz> and then we win.
Does this sounds reasonable? I'd like to put it into practice if there are
no objections.
Could you elaborate on the problem a little more? Is Servo creating its
own proxy handlers, or is it trying to piggyback on other proxy
handlers? We already have three reserved slots available for proxy
handlers to use. Is that not enough?
This sounds like a major change to the engine. Is the idea to
dynamically generate JSClasses? Or would there be some kind of macro
system to generate them statically for each handler?
-Bill
_______________________________________________
dev-tech-js-engine-internals mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-tech-js-engine-internals
