Tu ne prouve que ton manque de compréhension de ce dont tu parle.
Bien sûr que si. La seul chose c'est qu'effectivement l'OS limite le phénomène et généralement la corruption est limité au programme qui tourne et arrive très rarement aux autres programmes/drivers et exceptionnellement à l'OS.
Non et ce n'est pas généralement si ça existe c'est un bug enregistré dans une CVE a haute priorité.
La fuite mémoire c'est quand tu alloue de la mémoire en boucle sans jamais la libéré. Or en Java comme tu sais que tu ne peux pas "oublier" de libérer la mémoire gâce au garbage collector, naturellement, tu fais moins attention. En Rust, cette fuite est possible mais bien moins courante car il le programme doit prévoir de libérer sa mémoire par conception. Mais évidemment si tu fait un appel récursif infini (Ou trop important..) par exemple, fatalement, dans un cas comme dans l'autre tu crash.
Les cas de fuites mémoire en java sont identiques en rust. Rust ne te demande pas de prévoir la libération, il s'assure qu'une zone mémoire n'a qu'un et un seul propriétaire a aucun moment il ne fait quoi que ce soit pour que ce propriétaire ne garde que ce dont il a besoin.
PS : l'OOM killer, est une "option" sous Linux (par défaut sur la plupart des distribs) mais pas toujours présente. Il est une sécurité pour éviter de crasher l'OS faute de mémoire.
Qu'elle distribution retire cette option ?
Mais en Rust, on a une exception que l'on est censé traité.
Et comme elle ne s'appelle pas NullPointerException ça n'a rien à voir ?
C'est simple, quand un programme crash il fait n'importe quoi autrement dis il peut faire du dégât comme en C ou il peut aller ailleurs dans la mémoire et écraser tout et n'importe quoi. Mais pire, il peut ne pas planter, et continuer avec des donner qu'il a totalement pourri. Souvent d'ailleurs le crash réel intervient longtemps après.
Un crash de programme n'est pas propre quand il ne crash pas ?
En Rust et en Java on a une exception. La mémoire n'est pas corrompu et si on gère "l'exception" on peut utiliser les données car elles restent bonnes (Elles n'ont pas été altérées par le programme).
Tout le monde se fout de la mémoire au moment d'un crash. Éventuellement tu peux demander à la jvm de la dumper pour un post-mortem, mais corrompre sa mémoire lors d'un crash n'a pas de sens. Le processus est en cours de libération, le noyau va nettoyer les pages mémoires qui lui était allouées (non pas pour une question de corruption, mais pour éviter la fuite de données quand les pages seront réutilisées).
Evidemment, en Rust comme en Java, tu peux par bug, faire entrer le programme dans un comportement impossible et corrompu malgré tout (Par exemple mettre 400° dans un angle censé être entre 0 et 360). Ada est le langage ultime pour ça mais il est encore bien moins productif...
[^] # Re: Et en plus
Posté par barmic 🦦 . En réponse au lien Java is becoming more like Rust, and I am here for it!. Évalué à 6.
Tu ne prouve que ton manque de compréhension de ce dont tu parle.
Non et ce n'est pas généralement si ça existe c'est un bug enregistré dans une CVE a haute priorité.
Les cas de fuites mémoire en java sont identiques en rust. Rust ne te demande pas de prévoir la libération, il s'assure qu'une zone mémoire n'a qu'un et un seul propriétaire a aucun moment il ne fait quoi que ce soit pour que ce propriétaire ne garde que ce dont il a besoin.
Qu'elle distribution retire cette option ?
Et comme elle ne s'appelle pas NullPointerException ça n'a rien à voir ?
Un crash de programme n'est pas propre quand il ne crash pas ?
Tout le monde se fout de la mémoire au moment d'un crash. Éventuellement tu peux demander à la jvm de la dumper pour un post-mortem, mais corrompre sa mémoire lors d'un crash n'a pas de sens. Le processus est en cours de libération, le noyau va nettoyer les pages mémoires qui lui était allouées (non pas pour une question de corruption, mais pour éviter la fuite de données quand les pages seront réutilisées).
Tu confond bug, corruption de mémoire, crash,...
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll