Skip to content

Meeting 2013 11 25

Jump to bottom
Lars Bergstrom edited this page Nov 26, 2013 · 2 revisions

Servo Meeting 2013-11-25

Agenda

Attending

  • 16:40: azita, jdm, kmc, pcwalton, SimonSapin, Samsung team
  • 17:00 above + lbergstrom, dherman, jack

Early part of meeting (16:40 SF time)

  • samsung: It seems that Samsung's IP is blocked by Mozilla IRC
  • jdm: Could be the connection limit
  • pcwalton: We can get that raised
  • azita: How did office hours with jack go? Were you able to connect via Vidyo?
  • samsung: Yeah, it worked okay
  • azita: Maybe reduce the number of connections, call from one or two laptops?
  • samsung: We're just using one connection
  • azita: Maybe the connection is just worse today
  • azita: Can we resume at 5 with Lars and Jack (20 minutes)?

NVIDIA drivers

  • lars: patrick, what is the right way to start addressing the crashes? work around them temporarily?
  • pcwalton: issue #?
  • lars: there's the RGB/RGBA issue...
  • pcwalton: that can be worked around with two textures
  • kmc: I don't know if drivers are crashing or simply don't support all opengl things we need
  • lars: should we be expecting things to just work?
  • pcwalton: basic compositor stuff should. maybe x hasn't caught up to having transparent windows yet.
  • kmc: can send alpha channel separately, combine them with a fragment shader. I have found nouveau to be crashy when using it myself, so maybe not a good solution. quite surprised that nvidia drivers don't support this, since in general have been quite good historically.
  • lars: junyoung mentioned that servo didn't crash on the machine I set up, but did for her.
  • jack: do we know the specific feature we're trying to enable?
  • kmc: setting a rgba texture as a glxpixmap (???)
  • lars: I'll follow up with kmc offline and look into getting it fixed
  • kmc: I've switched to intel graphics for now, but would like to switch back. one of us should be able to write the two pixmap thing. if we know nvidia people we could reach out, but at some point we'll need to support older driver versions.
  • jack: hopefully in two years it won't be a problem.

IDE development

  • samsung: thinking of creating sublime text plugin. looking for required features.
  • jack: things people use in other editors are build trigger support, syntax checking (like pradeep's demo), tag support (find symbol in project). my understanding is that biggest hole in rust tooling is debugging.
  • samsung: unique feature of rust is owned pointer/memory structure; is there way to highlight this in IDE?
  • pcwalton: could do something like show where value is destroyed/moved.
  • kmc: could show extent of freezes when borrowing something mutable. maybe more of a question for rust team and other people who have thought more about this.
  • jack: short answer is we don't have required features, since existing tools are quite primitive. are you thinking of focusing on sublime text only, or including other editors like eclipse, or building something more general for generic integration with editors?
  • samsung: haven't decided. sublime is an example; we're considering eclipse and others.
  • dherman: jack, can you email the scala tool to the group?
  • jack: yes. it's Ensime (https://github.com/aemoncannon/ensime)

License

  • samsung: internally, need to go through license and look for issues. experience with other companies that try to commercialize spidermonkey/other products? need to show that later we won't have issues due to licensing.
  • dherman: probably worth talking to firefox os. I'll find out.
  • samsung: have apache, MPL...
  • dherman: do you want to know if there are issues, or do you have some right now?
  • samsung: just need to prove there won't be any.
  • dherman: firefox os team has most experience explaining how open source licenses work with commercial entities. I'll get back to you with their feedback.

PR updates

  • jack: 1298 looks like it's waiting on second round of review. anything particular to discuss?
  • pcwalton: I'll look at it.
  • jack: I'll look at fragment navigation (1262)
  • june0cho: when I first access the html page, we can link the fragment at #top. I think it should not reload the whole page.
  • jack: that sounds right. eventually, we won't have the whole page reflow anyway, probably what should happen is when we respond to the load event with a fragment navigation piece, currently you scroll to the y coordinate. In the future, we can scroll down and only repaint the segment of the page that is now displayed. What I saw in Korea looked fine. Is there another problem currently?
  • june0cho: I tried to only paint only one part, but I ran into some problems. I will ask about them in IRC later.

string interning

  • ryanc: question about string interning. Didn't have a chance to talk when you came here. I went through the thread. I didn't understand the requirements for string interning. Not clear to me on how to handle the concurrency. Do you have any ideas?
  • jack: Discussion with roc was that we don't need to be concurrent because the strings are only going to be updated in one (sequential) place and we can have a local cache for each task.
  • pcwalton: that's right. The only time we need concurrent string interning is if we had multitthreaded parsing.
  • kmc: But we definitely want concurrent parsing in the long run. Maybe just create a hashmap that isn't concurrent now and get it working. Later, we can just put a lock around it for a parallel prototype, and if that doesn't scale, write something more complicated.
  • ryanc: Do we also need to consider concurrency now?
  • pcwalton: I would not right now. Concurrent parsing we would like to do, but the problem is we don't know whether it will be a large speedup. We would like a single-threaded benchmark to compare the performance anyway. So, it's a good idea to have a non-multi-threaded hashmap for interning for now. Then, when we do multithreaded parsing, we'll have somethign to compare against.
  • kmc: I agree. And then we have a good baseline for comparing.
  • ryanc: I have a prototype I'm working on. I'll assume that the interning will happen on only one thread. I will not consider concurrency.
  • jack: I think it's fine to have multiple tasks doing interning, but they should each have a local cache.
  • kmc: But then we can't do equality comparisons between them. Fine for separate pipelines, but not for tasks within a single pipeline.
  • jack: Where would you be comparing equality that you don't have a copy of the string?
  • kmc: We want to not have to compare the strings...
  • jack: The main use case is going to be doing string comparisons in the script task, which is also what's doing the parsing, so no issue there. Where elseis going to be doing comparisons against things in another process where we can't afford...
  • simonsapin: which task is doing selector matching?
  • kmc: script, which is doing parsing.
  • pcwalton: wait, no, layout does it, but it doesn't intern anything. script does the interning. The only problem we might have is if HTML parsing is on multiple threads. Then you'll have to synchronize on it.
  • kmc: CSS parsing, too, right?
  • pcwalton: CSS parsing shouldn't have to intern.
  • kmc: when you encounter a rule with ids and tags...
  • jack: We have a PR for parallel CSS lexing...
  • pcwalton: I don't think it interns anything. Just ID names, which script would already have seen when parsing.
  • kmc: lookup by IDs? So, it needs the intern IDs in order to look up
  • simonsapin: aren't we parsing CSS in parallel with HTML?
  • pcwalton: Oh, that's a good point!
  • jack: There's a patch for it.
  • pcwalton: For now, one intern table. Make it concurrent if we need to later. Concurrent hash maps are not that slow. Can just do it java style.
  • simonsapin: I don't think it's going to help selector matching if they're not interned as well.
  • pcwalton: strings not interned by the HTML parser can't be found anyway by CSS selector matching (since they're unused and therefore unmatchable in the document)
  • jack: Let us know if you find any tricky cases that will not work with a non-concurrent hashmap, ryan. We can adjust the plan later if this solution will not work.

Rust ARM port

  • ryanc: "make check" does not check the arm port impl. We asked brson to turn it on, but he has not turned it on yet.
  • pcwalton: He's been working on that for the past week. He is on vacation for this week (US Thanksgiving, which is this Thursday/Friday for all of Mozilla).

Build system

  • jack: Current rustpkg work landed. kmc and jack did it. Has some drawbacks: it's only partially done in servo -- lots more to convert the rest of servo. I ran into some problems with rustpkg, so I decided to try some different things. I tried to fix one of the issues with the current use of other build systems, which required fixing Rust's generation of random names for the dynamic libraries. Using that, I was able to write a CMake script that can find them as well as tup + lua code for building Rust. All of those build systems have integration with C++. I am trying to figure out what we want to do going forward to make the builds faster and more reliable. Numbers: had to turn off parallel builds on servo. Made builds 30% slower. Submodules are in parallel, but top-level cannot.
  • kmc: Bad. Before we could build all the C++ deps while Rust was building.
  • jack: That's terrible. On my machine with -j10, 1 minute 30s to 2 minutes 30s.
  • kmc: What's the rustpkg bug that's preventing us from doing parallel builds?
  • jack: It's not a bug. rustpkg can't be run twice. It's a problem shared with CMake, tup, ninja - anything that keeps state in a central place can't be used by multiple process. Problem for rustpkg because normally you don't need two versions of cmake/tup/ninja at the same time. With rustpkg, we can't do that because we're scripting the toplevel from make, not rustpkg. We could possibly get the parallelism back for the rest of servo but not for the Rust bits. We'd need a separate Makefile for the rust that turns off parallelism (.NOTPARALLEL flag).
  • jack: So, should we maybe move to something else? Options: live with current broken, unreliable build system? It works, but keep geting slower. Option2: fix rustpkg. Probably lots of work. Option3: different build system (e.g., cmake or tup). I did some experiements with cmake and tup, which both work well. Do people have opinions? Or think this is a problem or not? Timing for skia submodule: in servo, 17second; in ninja OR tup, 12seconds (from clean). For a do-nothing/incremental build, in servo 1.5s, ninja OR tup 0.3s. That price (the do-nothing) saves us on every build.
  • jack: CMake generates the ninja files. tup is similar to ninja, but does not need to be generated. Both are much faster and more reliable. Some pain in conversion. But it'd be much simpler than what we have right now. The issue is that it's not rustpkg. Does anyone have a favorite build tool? CMake? Tup? Let me know. I don't want to choose something nobody wants to work on. And if you think we have to stick with rustpkg, that's fine.
  • pcwalton: tup is fine. We have internal support for tup. And we have no rustpkg resources right now.
  • jack: This came up because after spending time with Samsung in Korea, I realized we need to prioritize Windows more. In order to build there, we have to change our build in some way because there are too many assumptions. Both CMake and tup seem more suitable on Windows. Also, every browser vendor has a system they implemented themselves for their build. We would be the first to use something off-the-shelf.
  • pcwalton: shoudl we just use tup in general for rust code?
  • jack: I'll bring it up at the rust meeting tomorrow to see what the rust folks think. Sounds like nobody is saying to stop, so I will keep looking into it.
  • kmc: I agree. Our current Makefiles are terrifying and will only get worse with Windows support. Currently it's not good. The status quo with rustpkg is also not good. The only question is: should the servo team be working to make rustpkg better?
  • jack: I'll post some examples to the list so people can see what the makefiles look like to give more informed opinions.

selector matching

  • pradeep: I have a question for Simon/patrick. Was looking at gecko code for selector matching. Before they start doing selector matching on the node... rule hash... and the next time if there has been no modification to the stylesheet, they use the same rule hash again. In servo, every time we add a stylesheet, we insert all the rules in the rule hash and throw the stylesheet away. If we want to handle dynamic style, we have to store the stylesheet and build the rule hash only when we are about to match something. Any thoughts?
  • pcwalton: I agree. We're probably going to need use the damage. When there's damage done that results in the CSS change, then we need to rebuild the rule hash.
  • simonsapin: we definitely need to do this. I'm not sure how to have the same data inside the rule hash and inside the stylesheets. Preferrably using safe pointer from the type system. I'm not sure how to make the lifetimes work.
  • jack: Part of the tree in gecko that's immutable? Can't we use RC<> types? I know that some of the selector matching stuff is immutable and some is mutable. For immutable, we can use the RC<> types and as many things as need can hang onto it. If it has to be mutated, it'll be different.
  • pcwalton: Not sure how it will perform, but good to try.
  • jack: We should do what gecko does in general. Haven't heard from gecko engineers that it's something we should do better. They are unhappy with the size of the rules.
  • simonsapin: size of the selector
  • jack: If it's an optimization in gecko, we should match it in servo.
  • pcwalton: Agreed.
  • jack: Let us know if you have trouble and we can try to find solutions.
  • pradeep: Will do.

Meeting change

  • azita: Can we update this meeting to 4pm with the right conference room and number? Now 4pm PST. Also, there was some confusion about the video room.
  • jack: When does daylight savings stop in korea
  • ryan: We don't have it.
  • jack: Awesome! You're more enlightened than us. I will move the meeting as soon as I get my computer back.
  • simonsapin: Can we schedule the meeting in Korean Standard Time instead?
  • azita: Yes, then it should float.
  • jack: That's 9AM Korean Standard Time.
  • azita: So 4PM is 9AM there...
  • jack: I'll try to fix it to Korean time so there is less confusion in the future.

Office hours

  • jack: I will not be doing it this week because of the US holiday. I will send a reminder.
Clone this wiki locally