Gestion de la mémoire : changement sur le Mac App Store

Mickaël Bazoge |

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.

avatar Xalio | 

OS X et iOS avec une couche systeme unifiée.... Ca arrive!

avatar Steve92340 | 

C'est quoi garbage collection?

avatar Apollo11 | 

@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.

avatar Domsware | 

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

avatar oomu | 

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.

avatar BeePotato | 

@ 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.

avatar Domsware | 

@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.

avatar lmouillart | 

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.

avatar XiliX | 

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.

avatar Domsware | 

@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.

avatar BeePotato | 

@ 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.

avatar Domsware | 

@BeePotato :
Une des nouveautés de Swift est l'utilisation de valeurs de type qui ne sont pas des objets.

avatar BeePotato | 

@ 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.

avatar Domsware | 

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.

avatar BeePotato | 

@ 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.

avatar BeePotato | 

@ 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.

avatar juIien76 | 

Merci pour les copier coller de Wikipedia.

avatar aldomoco | 

@juIien76

... mon pater disait pour son dictionnaire "le guide âne" (bien que cela n'est aucun rapport,il faut dire qu'il était cycliste) !

avatar marc_os | 

@aldomoco :
Heureusement que ton père n'_est_ pas un rapport, sinon il se serait retrouvé dans les pignons !
;-)

avatar aldomoco | 

@marc_os :

.... chemin Faisant, tu as l'air d'en connaitre un rayon ;-)

avatar feefee | 

@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 ... :-)

avatar aldomoco | 

@feefee

..;perso j'utilise autant wiki que mon père utilisait son "guide âne" très pratique et enrichissant !

avatar jipeca | 

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 ?

avatar Domsware | 

@juIien76 :
Remarque stupide. Et méprisante pour les personnes qui ont pris le temps de rédiger des réponses.

avatar FreddyF | 

ARC est un vrai progrès par rapport au Garbage Collector.
ARC compte en temps réel les "pointeurs" vers un objet : si plus rien ne pointe vers un objet, celui-ci est automatiquement et immédiatement desalloué de la mémoire.
Alors que le Garbage Collector est une technique qui consiste, à intervalles réguliers, à évaluer si des objets sont encore nécessaire et à les purger. C'est un peu le principe de la voiture-balai.
ARC facilite grandement la gestion de la mémoire par les développeurs puisque ce compte de pointeurs est fait automatiquement (avant iOS 5, il fallait soi-même allouer et desallouer la mémoire, avec les risques de crash que cela comporte).

Pages

CONNEXION UTILISATEUR