On 2/13/13 11:19 PM, Patrick Walton wrote:
Servo now ships a known-working version of Rust, so it should be easier
to build.

Ah, excellent.  I should try again!

Fixing this will require the
scheduler rewrite that brson is currently working on. As per the current
plan for the rewrite, content will be able to atomically steal the
sleeping layout task and context switch into it if it is sleeping, which
should be very fast; overhead over a function call is one atomic
operation plus some more register saves/restores.

That sounds like it should be fast enough, yes. We should verify that it actually is in practice. Which to me suggests that the scheduler rewrite is a higher priority than, say, floats. At least if they're both gated on brson. ;) Do we have any ETA on the scheduler rewrite?

Maybe for a performance test we could just have the layout spin in a
separate thread. Communication is lock-free as long as the layout task
is awake at the time of the send. This may not be as fast as the
sleeping case under the scheduler rewrite, however, because it increases
the multi-CPU bus traffic.

Not as fast might be ok if we measure it that way and it's still fast enough. The thing to watch out for is accidentally measuring unrealistically fast things here.

A simple frontend to establish the multi-process model. The rationale is
that getting multi-process working early is better than putting it off
to avoid the situation we are in with Gecko.

Gotcha.

I plan to write up my thoughts more on the wiki tomorrow, but I am
currently leaning toward not using copy-on-write and instead just having
the DOM objects' contents be immutable while layout is running.

Hmm. This loses us a lot of the "quickly return to the event loop and page script" benefit we're ideally aiming for, I think. It also makes doing any sort of speculative layout much more problematic, right?

Why the change of heart here? Or should I just wait for your writeup on the wiki which will cover that?

This is basically the way Gecko and WebKit do it

Well ... yes. And it's a serious source of user-visible and script-visible jank in both.

so this reduces the single-threaded performance risk.

Not sure what this means.

For now JS will just block if it wants to mutate the DOM while layout is 
running. If we want JS to be able to
mutate the DOM while layout is running without blocking, then we could
add some sort of change queue or journal later on top of this design.

Hmm. How does _get_ performance on a modified DOM look in this approach? Just saying we can add some sort of thing is ... not quite enough. For this stuff the details really matter.

I think we should just ignore the fact that Rust cannot currently
inherit traits from structs for now

OK.  How temporary is "for now"?

and implement the DOM object methods
that have to be virtual using unsafe Rust code.

You mean non-virtual, right?

Basically we can just embed a vtable full of "extern fn"s into the structs that 
represent the
DOM and manually cast to obtain the self pointer.

How is this not virtual dispatch? I feel like I'm missing something, but I can't tell whether it's my lack of Rust knowledge or something else.

The endgame I would like to see for our DOM representation is that the DOM impl can write some sort of (presumably very simple) firstChild getter in safe Rust code and the binding can be generated in such a way that the compiler will inline the getter into the binding when all is said and done.

(Inheritance of traits from structs is the missing feature that we would need 
in Rust to make
this safe.) Later we can add that feature to Rust and make it safe. But
for now this would give us the right performance model: a struct with
flat fields, supporting a combination of nonvirtual and virtual methods.

That seems ok for basic performance sanity testing, sure. Not so great for actual implementation.

Do we have any ETA on inheritance of traits from structs? This also seems like a higher priority than floats.

Regarding stack switching, I have a proposal that has achieved tentative
consensus on the Rust team that should allow us to remove the stack
switching burden from the DOM task entirely for calls from Rust into the
JS engine and vice versa. So we should be good there.

Sounds great.

It needs to be implemented, of course.

This, too seems like a higher priority than floats.  ;)

-Boris
_______________________________________________
dev-servo mailing list
dev-servo@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-servo

Reply via email to