Gnirehtet réécrit en Rust
Il y a quelques mois, j’ai présenté Gnirehtet, un outil de reverse tethering pour Android que j’ai écrit en Java.
Depuis, je l’ai réécrit en Rust.
Et il est également open source ! Téléchargez-le, branchez un téléphone ou une tablette Android, et exécutez :
./gnirehtet run
(adb doit être installé)
Pourquoi Rust?
À Genymobile, nous voulions que Gnirehtet ne nécessite pas d’environnement d’exécution Java (JRE), donc le besoin principal était de compiler l’application vers un binaire exécutable natif.
Par conséquent, j’ai d’abord pensé la réécrire en C ou C++. Mais à ce moment-là (début mai), apprendre Rust m’intéressait, après avoir vaguement entendu parler de ses fonctionnalités:
Cependant, je n’avais jamais écrit une ligne de Rust ni entendu parler de son système de possession, d’emprunt ou de durées de vie.
Mais je suis convaincu que le meilleur moyen d’apprendre un langage de programmation est de travailler à plein temps sur un projet dans ce langage.
J’étais motivé, donc après avoir vérifié que ça pouvait convenir (en gros, j’ai écrit un exemple utilisant la bibliothèque d’I/O asynchrone mio, et je l’ai exécuté à la fois sur Linux et Windows), j’ai décidé de réécrire Gnirehtet en Rust.
Apprendre Rust
Pendant la réécriture, j’ai dévoré successivement le Rust book, Rust by example et le Rustonomicon. J’ai beaucoup appris, et j’aime énormément ce langage. Beaucoup de ses fonctionnalités me manquent maintenant quand je travaille sur un projet C++ :
- inférence de type avancée,
- enums,
- patterns,
- trait bounds,
Option<T>(commestd::optional<T>en C++17, mais tirant bénéfice des enums et des patterns),- macros hygiéniques,
- l’absence de fichiers d’en-têtes,
- le (si simple) système de build, et bien sûr
- la garantie de sûreté mémoire.
À propos de l’apprentissage, Paul Graham a écrit:
Reading and experience train your model of the world. And even if you forget the experience or what you read, its effect on your model of the world persists. Your mind is like a compiled program you’ve lost the source of. It works, but you don’t know why.
Pour les non-anglophones, ma propre traduction :
La lecture et l’expérience entraînent votre modèle du monde. Et même si vous oubliez l’expérience ou ce que vous avez lu, son effet sur votre modèle du monde persiste. Votre esprit est comme un programme compilé dont vous auriez perdu le code source. Ça fonctionne, mais vous ne savez pas pourquoi.
Certains des concepts de Rust (comme les durées de vie ou la sémantique de mouvement par défaut) m’ont fourni un jeu de données significativement différent, qui a sans aucun doute affecté mon modèle du monde (de la programmation).
Je ne vais pas présenter toutes ces fonctionnaliés (cliquez sur les liens de la documentation si ça vous intéresse). À la place, je vais essayer d’expliquer où et pourquoi Rust a resisté au design que je voulais implémenter, et comment repenser les problèmes dans le périmètre des contraintes de Rust.
La partie suivant nécessite une certaine connaissance de Rust. Vous pourriez vouloir la passer pour aller directement aux stats.
Difficultés
Je trouvais la conception de l’application Java plutôt réussie, donc je voulais reproduire l’architecture globale dans la version Rust (avec d’éventuelles adaptations pour la rustifier).
Mais j’ai lutté sur les détails, en particulier pour satisfaire le borrow checker. Les règles sont simples:
First, any borrow must last for a scope no greater than that of the owner. Second, you may have one or the other of these two kinds of borrows, but not both at the same time:
- one or more references (
&T) to a resource,- exactly one mutable reference (
&mut T).
En français :
Premièrement, aucun emprunt ne doit avoir une portée plus grande que celle de son propriétaire. Deuxièmement, vous pouvez avoir l’un ou l’autre de ces types d’emprunts, mais pas les deux à la fois:
- une ou plusieurs références (
&T) vers une ressource,- exactement une référence mutable (
&mut T).
Cependant, il m’a fallu un peu de temps pour réaliser comment elles entrent en conflit avec certains principes ou modèles de conception.
Voici donc mes retours. J’ai sélectionné 4 sujets qui sont suffisamment généraux pour être indépendants de ce projet particulier :
- les conflits avec l’encapsulation ;
- le design pattern observateur ;
- comment partager des données mutables ;
- un retour rapide sur les limitations ennuyeuses du compilateur.
Encapsulation
Les règles d’emprunt contraignent l’encapsulation. C’est la première conséquence que j’ai réalisée.
Voici un exemple canonique :
pub struct Data {
header: [u8; 4],
payload: [u8; 20],
}
impl Data {
pub fn new() -> Self {
Self {
header: [0; 4],
payload: [0; 20],
}
}
pub fn header(&mut self) -> &mut [u8] {
&mut self.header
}
pub fn payload(&mut self) -> &mut [u8] {
&mut self.payload
}
}
fn main() {
let mut data = Data::new();
let header = data.header();
let payload = data.payload();
}Nous créons juste une nouvelle instance de Data, puis associons à des
variables locales des références mutables vers les tableaux header et
payload, en passant par des accesseurs.
Cependant, cela ne compile pas :
$ rustc sample.rs
error[E0499]: cannot borrow `data` as mutable more than once at a time
--> sample.rs:21:19
|
25 | let header = data.header();
| ---- first mutable borrow occurs here
26 | let payload = data.payload();
| ^^^^ second mutable borrow occurs here
27 | }
| - first borrow ends here
Le compilateur ne peut pas faire l’hypothèse que header() et payload()
retournent des références vers des données disjointes dans la structure Data.
Par conséquent, chacun emprunte la structure data entièrement. Vu que les
règles d’emprunt interdisent d’obtenir deux références mutables vers la même
ressource, il rejette le second appel.
Parfois, nous faisons face à des limitations temporaires parce que le
compilateur n’est pas (encore) assez malin. Ce n’est pas le cas ici :
l’implémentation de header() pourrait très bien retourner une référence vers
payload, ou écrire dans le tableau payload, enfreignant ainsi les règles
d’emprunt. Et la validité d’un appel d’une méthode ne peut pas dépendre de
l’implementation de la méthode.
Pour corriger le problème, le compilateur doit être capable de savoir que les
variables locales header et payload référencent des données disjointes,
par exemple en accédant aux champs directement :
let header = &mut data.header;
let payload = &mut data.payload;ou en exposant une méthode fournissant les deux références simultanément :
struct Data {
fn header_and_payload(&mut self) -> (&mut [u8], &mut [u8]) {
(&mut self.header, &mut self.payload)
}
}
fn main() {
let mut data = Data::new();
let (header, payload) = data.header_and_payload();
}De même, dans l’implémentation d’une structure, les règles d’emprunt empêchent de factoriser du code dans une méthode privée facilement. Prenons cet exemple (artificiel) :
pub struct Data {
buf: [u8; 20],
prefix_length: usize,
sum: u32,
port: u16,
}
impl Data {
pub fn update_sum(&mut self) {
let content = &self.buf[self.prefix_length..];
self.sum = content.iter().cloned().map(u32::from).sum();
}
pub fn update_port(&mut self) {
let content = &self.buf[self.prefix_length..];
self.port = (content[2] as u16) << 8 | content[3] as u16;
}
}Ici, le champ buf est un tableau stockant un préfixe et un contenu de manière
contiguë.
Nous voulons factoriser la manière dont nous récupérons la slice content,
pour que les méthodes update_*() n’aient pas à se préoccuper des détails.
Essayons :
impl Data {
pub fn update_sum(&mut self) {
- let content = &self.buf[self.prefix_length..];
+ let content = self.content();
self.sum = content.iter().cloned().map(u32::from).sum();
}
pub fn update_port(&mut self) {
- let content = &self.buf[self.prefix_length..];
+ let content = self.content();
self.port = (content[2] as u16) << 8 | content[3] as u16;
}
+
+ fn content(&mut self) -> &[u8] {
+ &self.buf[self.prefix_length..]
+ }
}Malheureusement, cela ne compile pas :
error[E0506]: cannot assign to `self.sum` because it is borrowed
--> facto2.rs:11:9
|
10 | let content = self.content();
| ---- borrow of `self.sum` occurs here
11 | self.sum = content.iter().cloned().map(u32::from).sum();
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ assignment to borrowed `self.sum` occurs here
error[E0506]: cannot assign to `self.port` because it is borrowed
--> facto2.rs:16:9
|
15 | let content = self.content();
| ---- borrow of `self.port` occurs here
16 | self.port = (content[2] as u16) << 8 & content[3] as u16;
|
Comme dans l’exemple précédent, récupérer une référence à travers une méthode
emprunte la structure complète (ici, self).
Pour contourner le problème, nous pouvons expliquer au compilateur que les champs sont disjoints :
impl Data {
pub fn update_sum(&mut self) {
let content = Self::content(&self.buf, self.prefix_length);
self.sum = content.iter().cloned().map(u32::from).sum();
}
pub fn update_port(&mut self) {
let content = Self::content(&self.buf, self.prefix_length);
self.port = (content[2] as u16) << 8 | content[3] as u16;
}
fn content(buf: &[u8], prefix_length: usize) -> &[u8] {
&buf[prefix_length..]
}
}Ça compile, mais cela va totalement à l’encontre de la factorisation : l’appelant doit fournir les champs nécessaires.
Comme alternative, nous pouvons utiliser une macro pour inliner le code :
macro_rules! content {
($self:ident) => {
&$self.buf[$self.prefix_length..]
}
}
impl Data {
pub fn update_sum(&mut self) {
let content = content!(self);
self.sum = content.iter().cloned().map(u32::from).sum();
}
pub fn update_port(&mut self) {
let content = content!(self);
self.port = (content[2] as u16) << 8 | content[3] as u16;
}
}Mais c’est loin d’être idéal.
Je pense que nous devons juste l’accepter : l’encapsulation entre parfois en conflit avec les règles d’emprunt. Après tout, ce n’est pas si surprenant : imposer les règles d’emprunt nécessite de suivre chaque accès concret aux ressources, alors que l’encapsulation vise à les abstraire.
Observateur
Le design pattern observateur est utile pour enregistrer des événements sur un objet.
Dans certains cas, ce pattern pose des difficultés d’implémentation en Rust.
Pour faire simple, considérons que les événements sont des valeurs u32. Voici
une implémentation possible :
pub trait EventListener {
fn on_event(&self, event: u32);
}
pub struct Notifier {
listeners: Vec<Box<EventListener>>,
}
impl Notifier {
pub fn new() -> Self {
Self { listeners: Vec::new() }
}
pub fn register<T: EventListener + 'static>(&mut self, listener: T) {
self.listeners.push(Box::new(listener));
}
pub fn notify(&self, event: u32) {
for listener in &self.listeners {
listener.on_event(event);
}
}
}Par commodité, implémentons notre trait EventListener pour les closures :
impl<F: Fn(u32)> EventListener for F {
fn on_event(&self, event: u32) {
self(event);
}
}Ainsi, son utilisation est simple :
let mut notifier = Notifier::new();
notifier.register(|event| println!("received [{}]", event));
println!("notifying...");
notifier.notify(42);Cela affiche :
notifying...
received [42]
Jusqu’ici, tout va bien.
Cependant, les choses se compliquent si nous voulons modifier un état sur la réception d’un événement. Par exemple, implémentons une structure pour stocker tous les événements reçus :
pub struct Storage {
events: Vec<u32>,
}
impl Storage {
pub fn new() -> Self {
Self { events: Vec::new() }
}
pub fn store(&mut self, value: u32) {
self.events.push(value);
}
pub fn events(&self) -> &Vec<u32> {
&self.events
}
}Pour pouvoir remplir ce Storage sur chaque événement reçu, nous devons d’une
manière ou d’une autre le passer avec l’event listener, qui sera stocké dans
le Notifier. Par conséquent, nous avons besoin qu’une instance de Storage
soit partagée entre le code appelant et le Notifier.
Avoir deux références mutables vers le même objet enfreint évidemment les règles d’emprunt, donc nous avons besoin d’un pointeur à compteur de références.
Cependant, un tel pointeur est en lecture seul, donc nous avons également besoin
d’un RefCell pour la mutabilité intérieure.
Ainsi, nous allons utiliser une instance de Rc<RefCell<Storage>>. Cela peut
sembler trop verbeux, mais utiliser Rc<RefCell<T>> (ou Arc<Mutex<T>> pour
la thread-safety) est très courant en Rust. Et il y a pire.
Voici ce que donne le code client :
use std::cell::RefCell;
use std::rc::Rc;
let mut notifier = Notifier::new();
// first Rc to the Storage
let rc = Rc::new(RefCell::new(Storage::new()));
// second Rc to the Storage
let rc2 = rc.clone();
// register the listener saving all the received events to the Storage
notifier.register(move |event| rc2.borrow_mut().store(event));
notifier.notify(3);
notifier.notify(141);
notifier.notify(59);
assert_eq!(&vec![3, 141, 59], rc.borrow().events());De cette manière, le Storage est correctement modifié à partir de l’event
listener.
Tout n’est pas résolu pour autant. Dans cet exemple, c’était facile, nous avions
accès à l’instance Rc<RefCell<Storage>>. Comment faire si nous avons seulement
accès au Storage, par exemple si nous voulons que le Storage s’enregistre
lui-même à partir de l’une de ses méthodes, sans que l’appelant n’ait à fournir
l’instance Rc<RefCell<Storage>> ?
impl Storage {
pub fn register_to(&self, notifier: &mut Notifier) {
notifier.register(move |event| {
/* how to retrieve a &mut Storage from here? */
});
}
}Nous devons trouver un moyen de récupérer le Rc<RefCell<Storage>> à partir du
Storage.
Pour cela, l’idée consiste à rendre Storage conscient de son pointeur à
compteur de références. Bien sûr, cela n’a du sens que si Storage est
construit dans un Rc<RefCell<Storage>>.
C’est exactement ce que enable_shared_from_this fournit en C++, donc nous
pouvons nous inspirer de son fonctionnement : juste
stocker un Weak<RefCell<…>>, downgradé à partir du
Rc<RefCell<…>>, dans la structure elle-même. De cette manière, nous pouvons
l’utiliser pour récupérer une référence &mut Storage à partir de l’event
listener :
use std::rc::{Rc, Weak};
use std::cell::RefCell;
pub struct Storage {
self_weak: Weak<RefCell<Storage>>,
events: Vec<u32>,
}
impl Storage {
pub fn new() -> Rc<RefCell<Self>> {
let rc = Rc::new(RefCell::new(Self {
self_weak: Weak::new(), // initialize empty
events: Vec::new(),
}));
// set self_weak once we get the Rc instance
rc.borrow_mut().self_weak = Rc::downgrade(&rc);
rc
}
pub fn register_to(&self, notifier: &mut Notifier) {
let rc = self.self_weak.upgrade().unwrap();
notifier.register(move |event| rc.borrow_mut().store(event))
}
}Voici comment l’utiliser :
let mut notifier = Notifier::new();
let rc = Storage::new();
rc.borrow().register_to(&mut notifier);
notifier.notify(3);
notifier.notify(141);
notifier.notify(59);
assert_eq!(&vec![3, 141, 59], rc.borrow().events());Il est donc possible d’implémenter le design pattern observateur en Rust, mais c’est un peu plus difficile qu’en Java ;-)
Lorsque c’est possible, il est probablement préférable de l’éviter.
Partage de données mutables
Mutable references cannot be aliased.
En français :
Les références mutables ne peuvent pas être aliasées.
Comment partager des données mutables, alors ?
Nous avons vu que nous pouvions utiliser Rc<RefCell<…>> (ou Arc<Mutex<…>>),
qui impose les règles d’emprunt à l’exécution. Cependant, ce n’est pas toujours
désirable :
- cela force une nouvelle allocation sur le tas,
- chaque accès a un coût à l’exécution,
- l’emprunt concerne toujours la ressource entière.
Au lieu de cela, nous pourrions utiliser des pointeurs bruts manuellement dans du code non-sûr, mais alors ce serait non-sûr.
Et il y a une autre solution, qui consiste à exposer des vues temporaires d’emprunt d’un objet. Laissez-moi expliquer.
Dans Gnirehtet, un paquet contient une référence vers les données brutes (stockées dans un buffer quelque part) ainsi que les valeur des champs des en-têtes IP et TCP/UDP (parsées à partir du tableau d’octets brut). Nous aurions pu utiliser une structure à plat pour tout stocker :
pub struct Packet<'a> {
raw: &'a mut [u8],
ipv4_source: u32,
ipv4_destination: u32,
ipv4_protocol: u8,
// + other ipv4 fields
transport_source: u16,
transport_destination: u16,
// + other transport fields
}Le Packet aurait fourni des setters pour tous les champs d’en-têtes
(modifiant à la fois les champs du paquet et le tableau d’octets). Par exemple :
impl<'a> Packet<'a> {
pub fn set_transport_source(&mut self, transport_source: u16) {
self.transport_source = transport_source;
let transport = &mut self.raw[20..];
BigEndian::write_u16(&mut transport[0..2], port);
}
}Mais cette conception ne serait pas terrible (surtout que les champs d’en-têtes TCP et UDP sont différents).
À la place, nous voudrions extraire les en-têtes d’IP et de transport vers des structures séparées, gérant leur propre partie du tableau d’octets :
// violates the borrowing rules
pub struct Packet<'a> {
raw: &'a mut [u8], // the whole packet (including headers)
ipv4_header: Ipv4Header<'a>,
transport_header: TransportHeader<'a>,
}
pub struct Ipv4Header<'a> {
raw: &'a mut [u8], // slice related to ipv4 headers
source: u32,
destination: u32,
protocol: u8,
// + other ipv4 fields
}
pub struct TransportHeader<'a> {
raw: &'a mut [u8], // slice related to transport headers
source: u16,
destination: u16,
// + other transport fields
}Vous avez immédiatement repéré le problème : il y a plusieurs références vers
la même ressource, le tableau d’octets raw, en même temps.
Remarquez que diviser le tableau n’est pas une possibilité ici, vu
que les slices de raw se chevauchent : nous avons besoin d’écrire le paquet
complet en une seule fois vers la couche réseau, donc le tableau raw dans
Packet doit inclure les headers.
Nous avons besoin d’une solution compatible avec les règles d’emprunt.
Voici celle à laquelle je suis parvenu :
- stocker les données des en-têtes séparément, sans les slices de
raw, - créer des structures de vues pour les en-têtes d’IP et de transport, liées à une durée de vie,
- exposer des méthodes de
Packetretournant des instances de vues.
Et voici une simplification de l’implémentation réelle :
pub struct Packet<'a> {
raw: &'a mut [u8],
ipv4_header: Ipv4HeaderData,
transport_header: TransportHeaderData,
}
pub struct Ipv4HeaderData {
source: u32,
destination: u32,
protocol: u8,
// + other ipv4 fields
}
pub struct TransportHeaderData {
source: u16,
destination: u16,
// + other transport fields
}
pub struct Ipv4Header<'a> {
raw: &'a mut [u8],
data: &'a mut Ipv4HeaderData,
}
pub struct TransportHeader<'a> {
raw: &'a mut [u8],
data: &'a mut TransportHeaderData,
}
impl<'a> Packet<'a> {
pub fn ipv4_header(&mut self) -> Ipv4Header {
Ipv4Header {
raw: &mut self.raw[..20],
data: &mut self.ipv4_header,
}
}
pub fn transport_header(&mut self) -> TransportHeader {
TransportHeader {
raw: &mut self.raw[20..40],
data: &mut self.transport_header,
}
}
}Les setters sont implémentés sur les vues, où ils détiennent une référence mutable vers le tableau brut :
impl<'a> TransportHeader<'a> {
pub fn set_source(&mut self, source: u16) {
self.data.source = source;
BigEndian::write_u16(&mut raw[0..2], source);
}
pub fn set_destination(&mut self, destination: u16) {
self.data.destination = destination;
BigEndian::write_u16(&mut raw[2..4], destination);
}
}De cette manière, les règles d’emprunt sont respectées, et l’API est élégante :
let mut packet = …;
// "transport_header" borrows "packet" during its scope
let mut transport_header = packet.transport_header();
transport_header.set_source(1234);
transport_header.set_destination(1234);Limitations du compilateur
Rust est un langage jeune, et le compilateur a quelques problèmes ennuyeux.
Le pire, d’après moi, est lié aux durées de vie non-lexicales, qui provoque des erreurs inattendues :
struct Container {
vec: Vec<i32>,
}
impl Container {
fn find(&mut self, v: i32) -> Option<&mut i32> {
None // we don't care the implementation
}
fn get(&mut self, v: i32) -> &mut i32 {
if let Some(x) = self.find(v) {
return x;
}
self.vec.push(v);
self.vec.last_mut().unwrap()
}
}error[E0499]: cannot borrow `self.vec` as mutable more than once at a time
--> sample.rs:14:9
|
11 | if let Some(x) = self.find(v) {
| ---- first mutable borrow occurs here
...
14 | self.vec.push(v);
| ^^^^^^^^ second mutable borrow occurs here
15 | self.vec.last_mut().unwrap()
16 | }
| - first borrow ends here
Heureusement, cela devrait être corrigé prochainement.
La fonctionnalité d’Impl Trait, permettant aux fonctions de retourner des types abstraits non-boxés, devrait aussi améliorer l’expérience (il y a aussi une proposition étendue).
Le compilateur produit généralement des messages d’erreur très utiles. Mais quand ce n’est pas le cas, ils peuvent être très déroutants.
Sûreté et pièges
Le premier chapitre du Rustonomicon dit :
Safe Rust is For Reals Totally Safe.
[…]
Safe Rust is the true Rust programming language. If all you do is write Safe Rust, you will never have to worry about type-safety or memory-safety. You will never endure a null or dangling pointer, or any of that Undefined Behavior nonsense.
En français :
La partie Sûre de Rust est Réellement Totallement Sûre.
[…]
Le Rust Sûr est le vrai langage de programmation Rust. Si vous n’écrivez que du Rust Sûr, vous n’aurez jamais à vous inquiétez de la sûreté des types ou de la mémoire. Vous n’aurez jamais à supporter un pointeur null ou dangling, ou l’un de ces comportements indéfinis insensés.
C’est le but. Et c’est presque vrai.
Leakpocalypse
Dans le passé, il a été possible d’écrire du code Rust sûr accédant à de la mémoire libérée.
Cette “leakpocalypse” a conduit à la clarification des guaranties de sûreté : ne pas exécuter un destructeur est maintenant considéré sûr. En d’autres termes, la sûreté mémoire ne peut plus reposer sur RAII (en fait, elle n’a jamais pu, mais cela n’a été remarqué que tardivement).
En conséquence, std::mem::forget est maintenant sûr, et JoinGuard a
été déprécié et supprimé de la bibliothèque standard (il a été déplacé vers un
crate séparé).
Les autres outils s’appuyant sur RAII (comme Vec::drain()) doivent prendre
des précautions particulières pour garantir que la mémoire
ne sera pas corrompue.
Ouf, la sûreté mémoire est (maintenant) sauvée.
Infinité indéfinie
En C et C++, les boucles infinies sans effets de bords sont un cas d’undefined behavior. À cause de cela, il est possible d’écrire des programmes qui, de façon inattendue, réfutent le dernier théorème de Fermat.
En pratique, le compilateur Rust s’appuie sur LLVM, qui (actuellement) applique ses optimisations en faisant l’hypothèse que les boucles infinies sans effets de bords ont un comportement indéfini. En conséquence, de tels undefined behaviors se produisent également en Rust.
Voici un exemple minimal pour l’observer :
fn infinite() {
loop {}
}
fn main() {
infinite();
}Quand on l’exécute sans optimisations, il se comporte comme “attendu” :
$ rustc ub.rs && ./ub
^C (infinite loop, interrupt it)
Mais activer les optimisations fait paniquer le programme :
$ rustc -O ub.rs && ./ub
thread 'main' panicked at 'assertion failed: c.borrow().is_none()', /checkout/src/libstd/sys_common/thread_info.rs:51
note: Run with `RUST_BACKTRACE=1` for a backtrace.
Nous pouvons aussi produire des résultats inattendus sans plantage :
fn infinite(mut value: u32) {
// infinite loop unless value initially equals 0
while value != 0 {
if value != 1 {
value -= 1;
}
}
}
fn main() {
infinite(42);
println!("end");
}$ rustc ub.rs && ./ub
^C (infinite loop, interrupt it)
Mais avec optimisations :
$ rustc -O ub.rs && ./ub
end
C’est un cas particulier, qui sera probablement corrigé dans le futur. En pratique, les garanties de sûreté de Rust sont très fortes (au prix d’être contraignantes).
Erreur de segmentation
Cette section a été ajoutée après la publication.
Il y a d’autres sources d’undefined behaviors (voir les issues taggées I-unsound).
Par exemple, caster une valeur flottante ne pouvant pas être représentée dans le type cible est un undefined behavior, qui peut être propagé pour provoquer une erreur de segmentation :
#[inline(never)]
pub fn f(ary: &[u8; 5]) -> &[u8] {
let idx = 1e100f64 as usize;
&ary[idx..]
}
fn main() {
println!("{}", f(&[1; 5])[0xdeadbeef]);
}rustc -O ub.rs && ./ub
Erreur de segmentation
Stats
C’est tout pour mes retours sur le langage lui-même.
En supplément, comparons les versions Java et Rust du serveur relais.
Nombre de lignes
$ cloc relay-{java,rust}/src
-------------------------------------------------------------------------------
Language files blank comment code
-------------------------------------------------------------------------------
Rust 29 687 655 4506
Java 37 726 701 2931
-------------------------------------------------------------------------------
(tests included)
Le projet Rust est significativement plus gros, pour plusieurs raisons :
- il y a beaucoup de classes de vues d’emprunt ;
- la version Rust définit sa propre classe de selecteur d’I/O asynchrone,
encapsulant
Pollde plus bas niveau, alors que la version Java utilise leSelectorstandard ; - la gestion d’erreur pour l’analyse de la ligne de commande est plus verbeuse.
La version Java contient plus de fichiers car les tests unitaires sont séparés, alors qu’en Rust ils se trouvent dans le même fichier que les classes qu’ils testent.
Juste pour information, voici les résultats pour le client Android :
$ cloc app/src
-------------------------------------------------------------------------------
Language files blank comment code
-------------------------------------------------------------------------------
Java 15 198 321 875
XML 6 7 2 76
-------------------------------------------------------------------------------
SUM: 21 205 323 951
-------------------------------------------------------------------------------
Taille des binaires
--------------------------------------------
Java gnirehtet.jar 61K
--------------------------------------------
Rust gnirehtet 3.0M
after "strip -g gnirehtet" 747K
after "strip gnirehtet" 588K
--------------------------------------------
Le binaire Java lui-même est bien plus petit. La comparaison n’est pas juste cependant, vu qu’il nécessite l’environnement d’exécution Java :
$ du -sh /usr/lib/jvm/java-1.8.0-openjdk-amd64/
156M /usr/lib/jvm/java-1.8.0-openjdk-amd64/
Utilisation mémoire
Avec une seule connection TCP ouvert, voici la consommation mémoire pour le serveur relais en Java :
$ sudo pmap -x $RELAY_JAVA_PID
Kbytes RSS Dirty
total kB 4364052 86148 69316
(résultat filtré)
Et pour le serveur relais en Rust :
$ sudo pmap -x $RELAY_RUST_PID
Kbytes RSS Dirty
total kB 19272 2736 640
Regardez la valeur RSS, qui indique la mémoire réellement utilisée.
Comment on pouvait s’y attendre, la version Java consomme plus de mémoire (86Mo) que la version Rust (moins de 3Mo). De plus, sa valeur est instable à cause de l’allocation de petits objets et leur garbage collection, qui génère aussi davantage de dirty pages. La valeur pour Rust, quant à elle, est très stable : une fois la connection créée, il n’y a plus d’allocations mémoire du tout.
Utilisation CPU
Pour comparer l’utilisation CPU, voici mon scénario : un fichier de 500Mo est
hébergé par Apache sur mon ordinateur, je démarre le serveur relais avec perf
stat, puis je télécharge le fichier à partir de Firefox sur Android. Dès que le
fichier est téléchargé, je stoppe le serveur relais (Ctrl+C).
Voici les résultats pour la version Java :
$ perf stat -B java -jar gnirehtet.jar relay
Performance counter stats for 'java -jar gnirehtet.jar relay':
11805,458302 task-clock:u (msec) # 0,088 CPUs utilized
0 context-switches:u # 0,000 K/sec
0 cpu-migrations:u # 0,000 K/sec
28 618 page-faults:u # 0,002 M/sec
17 908 360 446 cycles:u # 1,517 GHz
13 944 172 792 stalled-cycles-frontend:u # 77,86% frontend cycles idle
18 437 279 663 instructions:u # 1,03 insn per cycle
# 0,76 stalled cycles per insn
3 088 215 431 branches:u # 261,592 M/sec
70 647 760 branch-misses:u # 2,29% of all branches
133,975117164 seconds time elapsed
Et pour la version Rust :
$ perf stat -B ./gnirehtet relay
Performance counter stats for 'target/release/gnirehtet relay':
2707,479968 task-clock:u (msec) # 0,020 CPUs utilized
0 context-switches:u # 0,000 K/sec
0 cpu-migrations:u # 0,000 K/sec
1 001 page-faults:u # 0,370 K/sec
1 011 527 340 cycles:u # 0,374 GHz
2 033 810 378 stalled-cycles-frontend:u # 201,06% frontend cycles idle
981 103 003 instructions:u # 0,97 insn per cycle
# 2,07 stalled cycles per insn
98 929 222 branches:u # 36,539 M/sec
3 220 527 branch-misses:u # 3,26% of all branches
133,766035253 seconds time elapsed
Je ne suis pas un expert pour analyser les résultats, mais de ce que je
comprends de la valeur task-clock:u, la version Rust consomme 4× moins de
temps CPU.
Conclusion
Réécrire Gnirehtet en Rust a été une formidable expérience, où j’ai appris un super langage et de nouveaux concepts de programmation. Et maintenant, nous avons une application native avec de meilleures performances.
Bon reverse tethering !
Discussions sur reddit et Hacker News.
