Meeting 2013-11-04: mac builder failure, priorities (C++, layout, parallelism, rustpkg, embedding, graphics)

[Josh Matthews]

https://github.com/mozilla/servo/wiki/Meeting-2013-11-04

[Robert O'Callahan]

I had a discussion with pcwalton and kmc yesterday about string interning.
The concurrent cuckoo hash table is cool but maybe not the right fit for
the browser workload for a couple of reasons:
a) interning lookups are mostly not on the hottest paths. They will occur
during parsing, and that can mostly happen off the main thread. Parsing
selectors for querySelectorAll etc would happen on the main thread (or at
least synchronously with it), but we cache parsed selectors in Gecko anyway
(as of recently). Also, we have the option of wrapping a thread-local cache
around the global intern table.
b) it's important to efficiently resize the table and shrink it by removing
unused atoms. That may not be easy to add to the concurrent cuckoo table.

Regarding new layout features, I think it's important to tackle some
architectural issues before adding more features:
-- Bidi and vertical text
-- Fragmentation (page/column/overflow:fragments breaking)
The former introduces abstractions that will be easier to introduce now
than any time in the future, since all your layout features will build on
them. The latter is a big architectural thing that will also be easier to
introduce now than in the future, and also may impact your design in
fundamental ways.

Rob
--
Jtehsauts tshaei dS,o n" Wohfy Mdaon yhoaus eanuttehrotraiitny eovni
le atrhtohu gthot sf oirng iyvoeu rs ihnesa.r"t sS?o Whhei csha iids teoa
stiheer :p atroa lsyazye,d 'mYaonu,r "sGients uapr,e tfaokreg iyvoeunr,
'm aotr atnod sgaoy ,h o'mGee.t" uTph eann dt hwea lmka'n? gBoutt uIp
waanndt wyeonut thoo mken.o w

[Patrick Walton]

On 11/5/13 2:11 PM, Robert O'Callahan wrote:
> I had a discussion with pcwalton and kmc yesterday about string interning.
> The concurrent cuckoo hash table is cool but maybe not the right fit for
> the browser workload for a couple of reasons:
> a) interning lookups are mostly not on the hottest paths. They will occur
> during parsing, and that can mostly happen off the main thread. Parsing
> selectors for querySelectorAll etc would happen on the main thread (or at
> least synchronously with it), but we cache parsed selectors in Gecko anyway
> (as of recently). Also, we have the option of wrapping a thread-local cache
> around the global intern table.
> b) it's important to efficiently resize the table and shrink it by removing
> unused atoms. That may not be easy to add to the concurrent cuckoo table.

Agreed. Also:

(c) We aren't really interested in a hash *table*, more of a hash *set*.
So lookup speed of *values* doesn't actually seem to me to matter much.

> Regarding new layout features, I think it's important to tackle some
> architectural issues before adding more features:
> -- Bidi and vertical text
> -- Fragmentation (page/column/overflow:fragments breaking)
> The former introduces abstractions that will be easier to introduce now
> than any time in the future, since all your layout features will build on
> them. The latter is a big architectural thing that will also be easier to
> introduce now than in the future, and also may impact your design in
> fundamental ways.

I think I have a handle on what needs to be done for the former, but the
latter is a bit opaque to me. Maybe a tutorial on what we need to watch
out for would be helpful :) I don't want to take up too much of
your/dbaron's time, but it'd be great to know what we need to watch out
for to avoid baking in bad assumptions.

Patrick