> 2) There is something strange going on with Splay GGC. We could be much
> faster on it. It seems like we are stuck in baseline on splay.js:49 for a lot
> of time! That function is doing nothing but returning a value, but somehow
> that takes 25% of the execution time (excluding gc). I guess so
I took the time to get tracelogging up and running again and create V2 out of
it. I think most know tracelogging already, but for those that don't:
Tracelogging traces when which scripts runs and which engine we use for it. Out
of the log information I create graphs showing when which engine is
On 7/19/13 12:47 AM, Boris Zbarsky wrote:
That's OK; neither do I. This is all pretty fuzzy so far...
Well, I do understand the overall kinda goal: Having the JS GC manage
all page-exposed memory so that there is no need for a cycle collector,
explicit trace hooks, etc. Basically, try to ma
On 7/19/13 12:33 AM, Bill McCloskey wrote:
I don't understand. Why do you need nodes that are not proxies? What would they
be instead?
Normal objects.
Most nodes are normal objects, in fact. Two types of nodes have
proxy-like behavior: forms and documents. Those are proxies. We
_could_ m
> 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 ob
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
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
On 7/18/13 5:21 PM, Bill McCloskey wrote:
It seems like we could use non-reserved slots on proxies.
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 a
On 07/18/2013 02:01 PM, Boris Zbarsky wrote:
So three reserved slots are not enough to the extent that DOM objects
have more than three members (and they do!).
It seems like we could use non-reserved slots on proxies. Basically, we
could pass the number of slots we want into ProxyObject::New,
On 7/18/13 4:55 PM, Bill McCloskey wrote:
Could you elaborate on the problem a little more? Is Servo creating its
own proxy handlers
Presumably yes, just like Gecko is right now. Basically one proxy
handler per WebIDL interface that has proxy-like behavior.
We already have three reserved s
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
On 7/18/13 4:46 PM, Josh Matthews wrote:
Does this sounds reasonable? I'd like to put it into practice if there are
no objections.
One more thing: if different handlers mean different JSClass for
proxies, that makes doing TI for proxies that much simpler: TI would
just keep track for proto +
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] So here's m
13 matches
Mail list logo
