Skip to content

Meeting 2013 07 15

Jump to bottom
Josh Matthews edited this page Jul 15, 2013 · 2 revisions

Servo Meeting 2013-07-15

Agenda

Attending

  • pcwalton, jack, dherman, eschweic, jdm, eatkinson, simonsapin, kmc, tikue

unanswered servo questions

  • pcwalton: i can address compositing, if you are just doing layout -> rendering -> compisiting, the fastest thing to do is to do it in one thread. that's why i've pushed to make cross task communication as fast as possible. message passing must be fast. things like task killing must be thrown out. part of the bet is that you'll be able to have multiple parts of the pipeline working in parallel and get speedups. compositing is the clear win here, and all browsers do it. people scroll the page while all sorts of things are going on. another win is rendering, it happens in parallel with other things. after JS performs some DOM manipulation, we run to the event loop to service events as quickly as possible. painting doesn't need to block the event loop. for layout, there's a decent chance that no one else is going to be running script and layout in parallel without getlcientrectasync. but that's still a win.
  • dherman: what does task killing mean?
  • pcwalton: the impelmentation for fancy task killing involves a mutex on every message send.
  • kmc: ghc supports sending async exceptions, but not sure how exactly they do it
  • pcwalton: we have task unkillable. when you do low level stuff you have to take into account you might be killed while doing it.

DOM wrapper

  • jack: let's talk about javascript wrappers. how can we measure lazy wrappers in gecko.
  • pcwalton: putting JS objects in the JS heap would make this moot. apparently we can put objects up to 18 words in the JS heap.
  • jack: do we think all the wrappers will fit in 18 words?
  • pcwalton: all of the common ones. probably looking at 90% of the wrappers
  • jack: and the other 10% would be created eagerly?
  • pcwalton: we'd create them in the JS heap but have a pointer to the extra that didn't fit. essentially works out to eager creation.
  • pcwalton: if we want to push on this, it will require some spidermonkey hacking and talking with terrance. we should have a meeting with him.
  • jdm: that sounds like the most promising to me. i've been getting lots of pushback from people with lots of experience optimizing DOM performance/memory usage and cycle collector maintenance and they think what we're doing now is absolutely insane.
  • dherman: didn't someone talk about lazily creating prototype hierarchies as well?
  • jdm: we will eagerly create prototype hierarchies for objects that are instantiated right now, so we don't use all the memory we could possibly be using.
  • dherman: tc39 is folding on mutable prototypes and putting it in the spec. it might make it more possible to create a dummy prototype and on demand mutating the prototype. i dont' know how to detect hte demand. the only way i know of to trigger prototype inspection is through proxies which is really expensive. object.setPrototypeOf and __proto. another tool to know about, but maybe it doens't help.
  • jdm: i'd be willing to sit down with terrance and figure out what kind of work is needed and do it as well. i have a reasonable amount of spidermonkey experience.
  • pcwalton: there are multiple fallback plans. isn't spidermonkey going to have to get the ability to allocate arbitrary objects into its heap because of binary data?
  • dherman: binary data is just triggering an allocation into a backing store, but the the object just has a pointer to the backing store. it's like typed arrays.
  • dherman: we should assume that we can modify spidermonkey. if there's something we need that's not exposed to web content, we can add it. it's just internal architecture and doesnt' affect the JS language.
  • pcwalton: chrome with oilpan is going towards putting everything into the js heap, we shouldnt' be thinign about GC + CC.
  • pcwalton: part of hte problem with the CC in gecko is that you have to manually annotate every object adding trace hooks to every C++ objects so it can say what it refers to. in oilpan they are adding trace functions to all webkit objects. it will be exactly as much fun as gecko. one advantage we have is that we control the compiler and we can have it maintain that stuff and keep it up to date. the advantage of letting the compiler do it, outweighs the choice of reclamation algorithm. that said we should still try to allocate in the GC heap because that simplifies everything.
  • dherman: the js team is willing to come to a meeting and answer questions, but they are strapped for dev time. but they are willing to help. don't be shy.

Viability

  • (lots of unrecorded discussion)
  • summary: timeline remains unclear, and not particularly useful to commit to one at this point. Criteria: people like roc say we must be at least as fast as Gecko for everything; DOM binding performance is critical, as is layout. How much layout implementation is required to give useful validation results? Acid 1? CSS 2.1? The space of further criteria requires discussion from people who understand the problem domain, and nobody has firm answers right now.
  • dherman: we should import as many benchmarks/performance harnesses from Gecko as possible, and create new ones if they don't demonstrate Servo's strengths effectively.
  • dherman: brendan wants impressive demos during 2013, and we seem to be well on the way.
  • (discussion of main problem of synchronous layout, how servo can lead to introduction of new APIs that return promises or have async interfaces to historically synchronous layout properties. Even if project crashes and burns, can lead to innovation in browser space and the web)
  • (discussion of off-main-thread-compositing and off-main-thread-rendering, something about how Servo won't end up triggering "checkerboarding" like many mobile browsers)
  • (sidebar about small library that works around synchronous layout by creating its own queue that runs at the end of the event loop: https://github.com/ebryn/backburner.js/ )

Work update

  • jack: png output. it's close; they're correctly oriented. problem with figuring out when ... so I have hardcoded calls to composite which I'm trying to get rid of. just taking whatever is showing in the window right now.

  • kmc: tracking down segfaul that occurs when scripttask told to exit.

  • jack: good, that will block reftests once I'm done.

  • simon: last week finished css parsing. caught up with rust and spec changes, now in the tree but not used yet. only the base syntax, no parsing of ... properties. next task is selector matching, starting with high level design.

  • pcwalton: maybe we should get a servo css working group with seth, simon, ..., myself, david zbarsky (author of parallel selector matching in gecko)

  • jdm: i've been doing more dom binding stuff. i'm sidetracked trying to get rid of hardcoded sizes, but i might give up on that as it's sort of a time sink.

  • pcwalton: i am mostly working on rust tracking down windows bugs. i have the cpu rendering patch that i keep rebasing. if i get more time to work on servo, then i will probably work on glfw touch support trying to get back smooth scrolling.

  • eatkinson: i finished up floats finally, and wikipedia looks nic enow. i'm thinking about taking a swing at parallel layout. it won't be fast yet because of selector matching, but it would be nice to get it designed.

  • eschweic: last week my tiling stuff landed, and i've been working on fixing bugs in that. want to work on multiple layers in the compositor so we can have some things that scroll and some that dont' and deleting usused tiles.

  • jack: things like position: fixed?

  • eschweic: yes

  • tikue: i'm close to finished with the refactor of constellation so it can handle multiple iframes. tehre's still stuff in the compositor with respect ot event handling that will take a bit of thinking. the layotu tasks are basically going to have to communicate with each other and there's some thinking that will need to go into that. any iframe can be resized, and because o fthat, iframes will need to block on parent frame layout so they can determine their own sizes. there's a lot to do still.

  • open questions re: compositing and multiple renderers:

    • If the compositor determines where to paint each tile based on pre-determined sizes, then any time layout is performed it will need to update those sizes
    • How will the compositor determine the correct script task to send events to e.g. for hit testing

  • open questions re: layout:

    • How will layout tasks communicate updated sizes to each other?
    • In what cases will one layout task handle multiple doms? If ever? Since we'll need to handle inter-layout communication even in the case of cross-origin iframes, multiple doms per layout may never be necessary.

  • jack: please use http://benjamin.smedbergs.us/weekly-updates.fcgi/ (requires a password, talk to jack / jdm)

Clone this wiki locally