Servo Architecture: Safety and Performance – Jack Moffitt
- History
- 1994 Netscape Navigator
- 2002 Mozilla Release
- 2008 multi-core CPU stuff not making firefox faster
- 2016 CPUs now have on-chip GPUs
- Very hard to write multi-threaded C++ to allow mozilla to take advantage of many cores
- How to make Servo Faster?
- Constellation
- In the past – Monolithic browser engines
- Single browser engine handling multiple tabs
- Two processes – Pool Content processes vs Chrome process
- If one process dies on a page doesn’t take out whole browser
- Sanboxing lets webpage copies have less privs
- Threads
- Less overhead than whole processes
- Thread per page
- More responsive
- Sandboxing
- More robust to failure
- Is this the best we can do?
- Run Javascript and layout simultaniously
- Pipeline splitting them up
- Child pipelines for inner iframes (eg ads)
- In the past – Monolithic browser engines
- Constellation
- Rust can fail better
- Most failures stop at thread boundaries
- Still do sandbox and privledges
- Option to still have some tabs in multiple processes
- Webrender
- Using the GPU
- Frees up main CPU
- Are VERY fast at some stuff
- Easiest place to start is rendering
- Don’t browsers already use the GPU?
- Only in a limited way for compositing
- Key ideas
- Retain mode not immediate mode (put things in optimal order first)
- Designed to render CSS content (CSS is actually pretty simple)
- Draw the whole frame every frame (things are fast enough, simpler to not try to optimise)
- Pipeline
- Chop screen into 256×256 tiles
- Tile assignment
- Create a big tree
- merge and assign render targets
- create and execute batches
- Text
- Rasterize on CPU and upload glyth to GPU
- Paste and shadow usign the GPU
- Using the GPU
- Project Quantum
- Taking technology we made in servo and put it in gecko
- Research in progress
- Pathfinder – GPU font rasterizer – Now faster than everything else
- Magic DOM
- Wins in JS/DOM intergration
- Fusing reflectors and DOM objects
- Self hosted JS
- External colaborations: ML, Power Mngt, WebBluetooth, etc
- Get involved
- Test nightlies
- Curated bugs for new contributors
- servo.org
In Case of Emergency: Break Glass – BCP, DRP, & Digital Legacy – David Bell
- Definitions
- BCP = Business continuity Plan
- A process to prevent and recover from business continuity plans
- BIP = Business interuptions plan
- BRP = Recovery plan
- RPO = Recovery point objective, targetted recovery point (when you last backed up)
- RTO = Recovery time objective
- Why?
- Because things will go wrong
- Because things should not go even more wrong
- Create your BCP
- Brainstorm
- Identify events that may interrupt, loss access to physical site, loss of staff
- Backups
- 3 copies
- 2 different media/formats
- 1 offsite and online
- Check how long it will take to download or fetch
- Test
- Who has the Authority
- Communication chains, phone trees, contact details
- Practice Early, Practice often
- Real-world scenarios
- Measure, measure, measure
- Record your results
- Convert your into an action item
- Have different people on the tests
- Each Biz Unit or team should have their own BCP
- Recovery can be expensive, make sure you know what your insurance will cover
- Breaking the Glass
- Documentation is the Key
- Secure credentials super important
- Shamir secret sharing, need number of people to re-create the share
- Digital Legacy
- Do the same for your personal data
- Document
- Credentials
- Services
- What uses them
- billing arrangments
- Credentials
- What are your wishes for the above.
- Talk to your family and friends
- Backups
- Document backups and backup your documentation
- Secret sharing, offer to do the same for your friends
- Other / Questions
- Think about 2-Facter devices
- Google and some others companies can setup “Next of Kin” contacts
