WIP: bincode IPC

[Gankra]

(based on my other PR that adds profiling; posting this now to discuss results)

Note: this adds a bincode dep to webrender-traits

This replaces the unsound transmute-based IPC with sound bincode-based IPC (results in subsequent comments).

---

This change is 

[Gankra]

I've only profiled Servo so far. Summary:

Mean IPC time goes from 0.5ms to 0.9ms with this change. Most of these losses are in deserialization time; some of it is in serialization time. It looks like most of this is when processing DisplayItems, and not AuxiliaryLists (need to dig into this, but it makes sense since AuxiliaryLists are relatively simple).

Note however that (de)serialization costs are suppressed by a surprising reduction in message send time, which appears to be the result of a reduction in the size of the message sent. Currently DisplayItems are ~twice as big as they could be in memory, and bincode manages to realize this size reduction. In principle this means transmute-based IPC could be reduced to ~0.3ms by just optimizing the layout of DisplayItems? However this may improve (de)serialization time too.

AuxiliaryLists seem to already be perfectly compact.

All in all this is pretty promising, considering the current implementation is completely naive. There's probably interesting wins to find in bincode::deserialize and DisplayItem layout.

Data:

transmute:

total IPC time:
    min:  0.35
    mean: 0.54
    max:  1.0

serial:   0.00
send:     0.5
deserial: 0.01

diplay-len: 211680
aux-len:    106300

bincode:

total IPC time:
    min:  0.70
    mean: 0.94
    max:  1.38

serial:   0.17
send:     0.3
deserial: 0.50

display-len: 111879
aux-len:     106688

(edit: note that the numbers don't perfectly sum because I was mostly eye-balling the serial/send/deserial means -- close enough for horse grenades)

[Gankra]

CC @TyOverby

[TyOverby]

There are a few optimizations that I'm going to be adding to bincode in the nearish future that might help webrender out:

• Variable-length number encoding for enum discriminants. Most enum discriminants will go from being u32 to u8, saving some space.
• The zero-copy API for serde will allow bincode to keep references to &str and &[u8] that are located in the original buffer. If you are serializing large strings or byte slices, this could prevent an extra memcpy.

[kvark]

@gankro thanks for the experiment and analysis!

Machine performance: transmute looks superior.
Human performance: Gecko folks would probably prefer leaving the transmute on.

Stability/portability: possible undefined behavior?
Code quality: bincode is cleaner, but then you'd just be shoving a transmute down the dependency line

[Gankra]

@kvark it's not so much a stability/portability issue as a "blatant hole in the multi-process security model". If the content process is hijacked, it can feed arbitrary bytes into the buffer, leading to undefined enum descriminants. This can in turn lead to trying to execute non-existent jump table slots (to name one obvious result of UB).

[TyOverby]

you'd just be shoving a transmute down the dependency line

@kvark: what do you mean by this?

[kvark]

@TyOverby
I mean that from the code quality point of view, it would make WR cleaner by reducing one more unsafe spot, but bincode probably has a few unsafe spots inside anyway, so this unsafety can be seen as just going down from WR to the dependency (bincode).

@gankro ok, makes sense. Would it be reasonable to look into asserting for the enum discriminants (as in - assert!(transmuted_value < target_enum_variant_count)? Or do you consider bincode inevitable?

[TyOverby]

bincode probably has a few unsafe spots inside anyway

That would be news to me!

As far as I can tell, the only unsafe is this one which is just an optimization avoiding zeroing out a Vec<u8>. Looking at the servo structs that are being serialized, I'm fairly certain that you never hit this code path to begin with, but I'd be happy to introduce a crate feature that doesn't include the optimization.

On top of this, bincode has been through several days of fuzzing, never hitting any vulnerabilities (it found a few panics that were immediately fixed). I'm using bincode in networked applications, so I'm pretty concerned about the security aspect of the project.

[kvark]

@TyOverby oh, right! My mistake then, thanks for correcting me :)

[Gankra]

@kvark bincode would be strongly preferred because we don't need to maintain it, but if I can't get the overhead low enough, the next avenue of exploration would be a fork of bincode that "happens" to match the Rust ABI exactly so that LLVM hopefully optimizes everything into transmute + validation.

[bors-servo]

☔ The latest upstream changes (presumably #1123) made this pull request unmergeable. Please resolve the merge conflicts.

[Gankra]

Replacing with new PR.