Gestion de la mémoire : changement sur le Mac App Store
Surprise pour les développeurs ce vendredi : à partir du 1er mai 2015, les applications soumises aux bons soins du Mac App Store ne devront plus accéder au « garbage collection » (GC), une méthode de gestion automatique de la mémoire déconseillée depuis OS X Mountain Lion mais qu’Apple autorisait tout de même… jusqu’au mois de mai, donc.
Les développeurs devront migrer leurs applications vers ARC (Automatic Reference Counting, introduit avec OS X 10.7), en utilisant l’assistant de migration disponible dans Xcode. Le constructeur livre une documentation sur le sujet. Apple y explique notamment que GC sera purement et simplement retiré d’une prochaine version d’OS X. Mieux vaut donc prendre tout de suite les devants : il leur reste moins de trois mois pour se conformer aux desideratas d’Apple.
OS X et iOS avec une couche systeme unifiée.... Ca arrive!
C'est quoi garbage collection?
@Steve92340 :
Selon la photo, ce sont des poubelles avec des fleurs. Mais on ne précise pas
quelle sorte de fleur. Ça m'intrigue.
Sérieux, je n'en ai aucune idée moi aussi.
C'est une technique de gestion de la mémoire : en gros lorsque le programme supprime des données c'est le système qui se charge de temps à autre de "vider la poubelle" afin de récupérer de la mémoire.
Une autre technique utilisée est que le programme vide la poubelle immédiatement après une suppression de données : jusqu'à présent c'était au développeur de gérer cela avec son lot d'oublis et d'erreurs. ARC permet de faciliter cela.
J'espère avoir été clair
Le Ramasse-miette (Garbage Collector) est une méthode pour récupérer automatiquement la mémoire vive qu'un logiciel alloue (demande de réservation au près du système, pour ensuite y mettre des données: l'allocation)
Un développeur peut allouer (réserver) puis plus tard libérer au cours du fonctionnement du programme et non au démarrage. Ainsi il s'assure que la mémoire de l'ordinateur est utilisée quand il faut et pas gaspiller.
Mais cela est contraignant et pénible: il ne faut jamais perdre trace des allocations (ce qui n'est pas si simple quand un logiciel complexe va réserver suite à divers scénarios pas facile à prédire) au risque de faire des "fuites de mémoire" : le logiciel va manger toujours + de mémoire vive tout le long de son fonctionnement.
C'est ce que les utilisateurs détestent: au bout d'un certain temps, le programme ralentit l'ordinateur vu que ce dernier n'a plus de mémoire vive et doit utiliser le stockage interne pour en simuler +. (le stockage, ssd ou disque dur, est + lent que la mémoire vive).
Le Garbage Collector ou "ramasse miette", libère le développeur de la gestion de la libération de la mémoire. Le GC va surveiller le programme, voir quand une structure en mémoire n'est plus nécessaire et la supprimer pour libérer la mémoire pour le système. Très pratique. C'est l'une des raisons pourquoi JAVA fut populaire rapidement.
Le Ramasse-miette est typiquement un concept de programmation orientée objet (POO) comme Objective-C, Swift, Java, C# etc. Le GC va suivre la vie et mort des "objets". Un objet qui n'est plus utilisé (le programme n'y fait plus référence) sera détruit (libération de la mémoire consommée pour que le système en fasse autre chose) par le GC.
Mais cela a un coût, un terrible coût: ça consomme des ressources processeurs. PIRE cela peut consommer de la batterie, car le GC doit être régulièrement activé pour faire le ménage dans le logiciel (la machine ne peut donc pas se mettre en veille)
Apple a tenté plusieurs optimisations avant de laisser tomber. En particulier à cause des limitations des iphones et ipad (la batterie)
-
ARC est une alternative au Ramasse-Miette. ARC est une méthode + rudimentaire mais nettement - consommatrice : c'est un ensemble de macros (instructions automatiquement ajoutée) que XCODE (l'outil de développement de Os X/iOS) va ajouter au code du logiciel, pendant le développement du programme, pour automatiser la libération de la mémoire si tôt qu'elle n'est plus nécessaire.
Ce n'est pas magique, le développeur doit suivre un formalisme et déclarer son logiciel compatible.
@ oomu : « Le Ramasse-miette est typiquement un concept de programmation orientée objet (POO) comme Objective-C, Swift, Java, C# etc. »
C’est typiquement pour ces langages (enfin, surtout Java et C#, car on peut considérer que la brève existence du GC pour Objective C n’était finalement qu’un accident, et Swift n’utilise pas de GC) qu’on trouve une implémentation de garbage collection, mais le concept lui-même n’est pas vraiment lié à la programmation orientée objet.
« ARC est une méthode + rudimentaire »
Pas si rudimentaire que ça, tout de même. Il faut être capable d’analyser proprement le code pour mettre cette approche en place.
Approche que, personnellement, je trouve bien plus élégante que le GC, puisque ARC consiste à automatiser une tâche que le développeur devait jusque là faire manuellement, tandis que le GC consiste à dédier des ressources à un processus en charge du nettoyage de la mémoire pour compenser le fait que personne — ni le développeur, ni le compilateur — ne s’est chargé de la gérer proprement.
@oomu :
De plus le GC se déclenchant au bon vouloir du système cela peut avoir des effets fâcheux. Notamment une augmentation de consommation des ressources à un moment où le programme en a besoin : le GC passe tranquillement le balai alors que le système a des besoins urgents. Ainsi cela peut entraîner des ralentissements perceptibles par l'utilisateur : pénible pour un jeu, catastrophique pour un contrôle d'automate.
ARC représente ainsi une solution élégante qui ne requiert pas l'attention du développeur dans la très grande majorité des cas.
Certaines implémentations de GC sont compatible avec une utilisation temps réel et ont un passage déterministe, typiquement celles disponible dans Websphere Realtime ou dans JamaicaVM.
Mais quelle bande de faineasse :D
On m'a toujours appris que les fuites de mémoire, il faut les trouver. Nâ !
Mais effectivement ARC est plus élégant comme solution.
@XiliX :
Ah ah ah ! On m'a dit cela aussi !
À noter que Swift permet désormais de se passer en grande partie de cette gestion fine et parfois complexe de la mémoire par le développeur.
@ Domsware : « À noter que Swift permet désormais de se passer en grande partie de cette gestion fine et parfois complexe de la mémoire par le développeur. »
Ben ce n’est pas une nouveauté de Swift, puisque ce dernier ne fait qu’utiliser le même concept d’ARC disponible pour Objective C depuis quelques années. On reste donc en terrain connu.
@BeePotato :
Une des nouveautés de Swift est l'utilisation de valeurs de type qui ne sont pas des objets.
@ Domsware : « Une des nouveautés de Swift est l'utilisation de valeurs de type qui ne sont pas des objets. »
Euh… peut-être suis-je un peu trop fatigué (il est déjà tard où je suis), mais j’avoue que là je ne vois pas à quoi tu fais référence, ni le rapport que ça peut avoir avec ARC et la gestion de la mémoire dans Swift.
Donc si jamais tu as quelques minutes pour détailler ce dont tu parlais, ça m’intéresse. Merci.
Je fais référence à des objets qui n'ont qu'un seul référant. Voici un exemple :
var a = [1, 2, 3]
var b = a
// a = [1, 2, 3]; b = [1, 2, 3]
b.append(4)
// a = [1, 2, 3]; b = [1, 2, 3, 4]
(tiré de l'article suivant : http://realm.io/news/andy-matuschak-controlling-complexity/)
On trouve cela dans d'autres langage notamment Ada.
@ Domsware : « Je fais référence à des objets qui n'ont qu'un seul référant. »
Ah, ok : le fait que les tableaux et dictionnaires de Swift soient traités par valeur et non par référence.
C’est une des décisions prise pour Swift dont je ne suis pas fan du tout. :-(
Mais de toute façon, à partir du moment où Swift utilise ARC, cette approche n’apporte pas de simplification supplémentaire à la gestion de la mémoire par les développeurs. Comme je l’ai dit, on retrouve vraiment ce qu’on avait déjà en Objective C.
@ XiliX : « Mais quelle bande de faineasse :D »
Ben… des développeurs, quoi ! ;-)
Cela dit, ARC suit un principe largement accepté en informatique : à partir du moment où une partie du boulot du développeur peut être automatisée, il est préférable d’avoir recours à cette automatisation, puisqu’elle permet d’obtenir le même résultat en supprimant (en théorie) le risque d’oubli qu’on trouve dans l’approche manuelle. Même si, au début, ça fait bizarre (et un poil frustrant) de ne plus écrire de retain/release. :-)
Mais attention : je parle bien d’une automatisation d’une partie de l’écriture, aboutissant au final au même résultat. Ce que le GC n’a jamais été. Avec le GC, on pouvait être bien plus tenté de parler de flemme des développeurs, puisqu’ils choisissaient de sacrifier des ressources à l’exécution pour ne pas avoir à faire la gestion manuelle de la mémoire.
« On m'a toujours appris que les fuites de mémoire, il faut les trouver. Nâ ! »
Notons que ça reste vrai, puisqu’avec ARC il faut toujours vérifier qu’on ne crée pas de cycles.
Merci pour les copier coller de Wikipedia.
@juIien76
... mon pater disait pour son dictionnaire "le guide âne" (bien que cela n'est aucun rapport,il faut dire qu'il était cycliste) !
@aldomoco :
Heureusement que ton père n'_est_ pas un rapport, sinon il se serait retrouvé dans les pignons !
;-)
@marc_os :
.... chemin Faisant, tu as l'air d'en connaitre un rayon ;-)
@juIien76 :
"Merci pour les copier coller de Wikipedia."
C'est une critique ? Tu penses donc que les participants ne connaissent pas leur sujet ?
Peut être parce que tu es dans ce cas alors ... :-)
@feefee
..;perso j'utilise autant wiki que mon père utilisait son "guide âne" très pratique et enrichissant !
Reflection totalement inutile, mais bon on est rodé !
En supposant qu'il ne connaisse pas le sujet, et t'en sais rien, en quoi ça déprécie sa remarque ?
@juIien76 :
Remarque stupide. Et méprisante pour les personnes qui ont pris le temps de rédiger des réponses.
Est-ce que cela va permettre sur OSX de jeter aux oubliettes la "sensation" de ralentissement de la machine au fur et à mesure de son usage ?
J'ai été étonné quand Apple avait introduit le GC. En effet, _le_ reproche qui lui a toujours été fait et que l'on retrouve dans les commentaires ici, c'est le ralentissement qu'il provoque régulièrement. Je l'ai découvert vers 1990 alors que je programmais en Common Lisp ! Suite à quoi je me suis mis au C...
@marc_os :
Il s'est passé des choses depuis 1990 ;)
@marc_os :
Sur le principe GC n'est pas une mauvaise idée. Le problème est que certains développeurs comptent trop sur GC pour nettoyer les fuites au lieu de prendre le temps nécessaire pour supprimer les fuites.
@XiliX :
Sur le principe. Mais ça fait juste 20 ans qu'en pratique ce n'est pas efficace malgré le bond en puissance énorme fait depuis. Et le GC n'est toujours pas efficace !
Bon débarras.
@marc_os :
C'est un peu facile de taper sur cette technologie par principe. D'expérience les ralentissements que j'ai vu sur des programmes Java (qui a de très bons GCs) étaient dûs à d'autre problèmes. Comme par exemple : lancer des traitements longs dans le thread de l'UI, ou créer sans arrêt des objets quand on navigue dans des listes.
@Mithrandir
Je ne dis pas que le GC est mal implémenté en Java...
Juste que malgré l'augmentation phénoménale de puissance des machines depuis 20 ans, GC semble toujours aussi difficile à mettre en œuvre de manière efficace.
Quoiqu'il en soit, je pense qu'ARC est la meilleure solution côté développements en Ojbective C. Le système allie efficacité et facilité de programmation. Par exemple pour savoir quand il fallait faire un retain sur un nouvel objet, il fallait tenir compte de la façon, via quelle API il avait été créé. Ce n'est plus nécessaire. Comme le disait quelqu'un plus haut, il ne reste plus qu'à faire gaffe aux références croisées entre objets. Mais la documentation d'Apple est bien faite et elle explique quelles solutions appliquer.
@ marc_os : « Par exemple pour savoir quand il fallait faire un retain sur un nouvel objet, il fallait tenir compte de la façon, via quelle API il avait été créé. Ce n'est plus nécessaire. »
Notons toutefois que ce n’était pas trop difficile de faire ça. La gestion de la mémoire avec Cocoa a toujours été simple à mettre en œuvre, grâce au comptage de références et à des conventions de nommage bien claires pour les méthodes retournant des objets.
M’enfin, il est vrai qu’une automatisation est toujours bonne à prendre, la petite faute d’inattention guettant le développeur au coin du code pour lui faire oublier un retain ou un release. :-)
@marc_os :
GC ne sera jamais 100% efficace car ça reste un problème probabiliste
@XiliX :
Renseigne toi ;)
Le GC ne supprime pas les fuites mémoires (memory leaks), il réalloue les blocs mémoires qui ne sont plus utilisés. Si on garde un pointeur sur un bloc mémoire non utilisé, le GC ne peut pas le supprimer, c'est une fuite, d'autant plus importante qu'elle peut s'accumuler.
@denmakesmusic :
Ça revient au même. Le fait de reallouer la fuite de mémoire, ça revient à circonscrire la fuite.
Code parlant effectivement non car la fuite est là
Encore du travail pour les développeurs qui ne leur apportera rien et leur fera perdre de l'argent car c'est du code technique et non métier. "Chef, il faut que je réécrive toute la gestion mémoire, ça va me prendre la semaine"
@denmakesmusic :
C'est juste le contraire ! :)
@ denmakesmusic
Si des développeurs considèrent qu'adopter une technique qui améliore la qualité de leurs logiciels c'est perdre du temps car, « c'est du code technique et non métier », et bien je ne voudrais pas de leurs logiciels. De même si c'est la vision de leur N+1.
Je reconnais là une certaine mentalité fréquente chez les auto-proclamés "consultants" qui font du « métier » leur priorité et qui crachent sur ce qui n'est pas de leur supposé niveau. Et qui fournissent de la merde boguée à mort et bien trop cher payée. :/
@marc_os :
Entièrement d'accord. De même, Swift apporte une certaine facilité d'écriture par rapport à Objective-C et c'est tant mieux. Tout ce qui tend à faciliter et clarifier l'écriture et l'utilisation des bonnes méthodes de programmation va dans le bon sens. Le Garbage Collection est une antiquité.
@ Finouche : « De même, Swift apporte une certaine facilité d'écriture par rapport à Objective-C et c'est tant mieux. »
Ah ? Pour ma part, j’ai tendance au contraire à trouver que Swift complexifie pas mal de choses.
@BeePotato :
C'est quoi ton métier? Tu as l'air de t'y connaître.
@ juIien76 : J’ai eu l’occasion de pratiquer plusieurs des nombreux métiers offerts par le vaste domaine de l’informatique, en me débrouillant toujours pour qu’il y ait une part (plus ou moins importante) de développement. Parce que c’est une activité qui me plaît beaucoup depuis un bon moment (depuis que j’ai découvert le Logo sur un Apple II). :-)
Du coup, oui, ça me permet de m’y connaître dans le domaine du développement. Mais il y a bien d’autres intervenants ici qui donnent tout autant l’impression de s’y connaître — et comme le monde du développement est vaste, les uns et les autres en maîtrisent des aspects différents, d’où l’intérêt d’intervenants multiples.
Je pense que vous racontez absolument n'importe quoi ;)