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
