1. John Siracusa
    1. Mountain Lion
      1. Introduction
      2. Achat et installation
      3. Changements d'interface (1)
      4. Changements d'interface (2)
      5. Changements d'interface (3)
      6. Applications (1)
      7. Applications (2)
      8. Applications (3)
      9. Applications (4)
      10. Applications (5)
      11. iCloud(1)
      12. iCloud(2)
      13. iCloud(3)
      14. Gatekeeper(1)
      15. Gatekeeper(2)
      16. Retina et HiDPI
      17. Fourre-tout (1)
      18. Fourre-tout (2)
      19. Fourre-tout (3)
      20. Fourre-tout (4)
      21. Fourre-tout (5)
      22. Fourre-tout (6)
      23. Recommandations
      24. Deux pères, un fils
    2. Lion
      1. Introduction
      2. Installation
      3. Revoir les fondamentaux
      4. Redimensionnement des fenêtres
      5. Et voici pour les cinglés
      6. La gestion des fenêtres
      7. Le modèle de document
      8. le modèle des processus
      9. Les éléments internes (1)
      10. Les éléments internes (2)
      11. ARC
      12. Le système de fichiers
      13. Ses modifications dans Lion
      14. Documents, résolution
      15. Le Finder
      16. Mail, Safari
      17. Fourre tout (1)
      18. Fourre tout (2)
      19. Recommendations
    3. Snow Leopard
      1. Introduction
      2. Le ticket d'entrée
      3. L'installation
      4. Nouvel aspect
      5. Détails internes
      6. Quick Time X
      7. Système de fichiers
      8. Faire plus avec plus
      9. LLVM et Clang
      10. Les blocs
      11. Concurrence
      12. Grand Central Dispatch
      13. Asynchronicité
      14. Open CL
      15. La différence...
      16. Quick Time Player
      17. Le Dock
      18. Le Finder
      19. Exchange
      20. Performances
      21. Fourre tout (1)
      22. Fourre tout (2)
      23. Le futur
    4. Leopard
      1. Introduction
      2. L'héritage
      3. Nouvel aspect 1
      4. Nouvel aspect 2
      5. Le noyau
      6. 64 bits
      7. FS Events
      8. Core animation
      9. Quartz GL
      10. Core UI
      11. Détails internes
      12. Le Finder
      13. Le Dock
      14. Time Machine
      15. Performances
      16. Pot pourri
      17. Demain
    5. Tiger
      1. Introduction
      2. Retour sur le passé
      3. Nouvel aspect de Tiger
      4. Mises à jour du noyau
      5. Le lancement
      6. Les méta-données
      7. Attributs étendus
      8. Listes de contrôle d'accès
      9. Spotlight 1
      10. Spotlight 2 : analyse et potentiel
      11. Types de fichiers
      12. Méta-données : la fin
      13. Quartz
      14. Quartz 2D Extreme
      15. Core Image
      16. La vidéo sous Tiger
      17. Dashboard
      18. Le Finder
      19. Les performances
      20. Pot pourri
      21. Conclusion
    6. Panther
      1. Introduction
      2. Les précédents
      3. L'installation
      4. Nouvel aspect
      5. Performances
      6. Changement rapide d'utilisateur
      7. Gestion des fenêtres
      8. Exposé
      9. Le Finder
      10. Performance du Finder
      11. Toujours le même
      12. Safari
      13. XCode
      14. Conclusion
    7. Jaguar
      1. Introduction
      2. Le nom
      3. L'installation
      4. Modifications d'Unix
      5. Dévelopeurs...
      6. Quoi de neuf
      7. Rendezvous
      8. Quartz Extrême
      9. Performance
      10. Compositions
      11. Le Finder
      12. Applications
      13. Sherlock
      14. Le portrait
    8. Puma
      1. Prelude
      2. Introduction
      3. Installation
      4. Réglages système
      5. Performance
      6. Redimensionnement des fenêtres
      7. Utilisation de la mémoire
      8. Diagnostics de mémoire
      9. L'environnement Classique
      10. L'interface Utilisateur
      11. Le Finder
      12. Extensions de fichiers
      13. Divers, conclusion
    9. Cheeta (Mac OS X 10.0)
      1. Qu'est ce que Mac OS X
      2. Installation
      3. Le démarrage
      4. Utilisation de la RAM
      5. Performance
      6. Performance des applications
      7. Stabilité
      8. L'interface utilisateur
      9. Le Finder
      10. Le navigateur du Finder
      11. Le Finder (divers)
      12. L'interface utilisateur
      13. Os X Classique
      14. Système de fichiers
      15. Unix
      16. Applications
      17. Conclusion
    10. Les débuts de MacOsX
      1. 1999 : OSX DP2
      2. 2000 : Quartz et Aqua/a>
      3. Fin de la lune de miel
      4. la première bêta publique
      5. 2001 : Mac OS X 10.0
      6. Un investissement
    11. Finder Spatial
      1. Introduction
      2. Interfaces spatiales
      3. Le Finder spatial
      4. Le concierge
      5. Un nouveau Finder
      6. Le browser
      7. Le browser spatial
      8. Finder et méta-données
      9. Les modèles
      10. Pensées finales

Lion (11)




ARC contre le ramasse miettes.

Le ramasse miettes pour Objective C d'Apple est intervenu avec certains désavantages. Comme je l'ai suggéré précédemment, le programmeur a peu de contrôle sur le moment où le ramasse miettes se met en route, ce qui rend la récupération des objets non déterministe. Une application avec ramasse miettes, avec une bogue de gestion de la mémoire peut se planter ou non, selon le moment où le ramasse miettes se met en route. Comme le ramasse miettes ne fonctionne que périodiquement, les "miettes" (de la mémoire) peuvent commencer à s'empiler entre les périodes de fonctionnement. Cela peut augmenter ce qu'on appelle la "hauteur de crue" d'une application. Et pour finir, le processus de ramasse miettes lui-même peut interférer avec l'exécution de l'application.

Même sur un CPU multicœurs, où le ramasse miettes peut tourner sur un thread (fil) différent, il doit encore interagir avec l'image mémoire de l'application en fonctionnement, en bloquant parfois (brièvement) sa progression quand il nettoie les miettes. Sur des CPUs relativement faibles, souvent ceux à un seul thread des mobiles, cette interférence peut se manifester par des bégaiements ou des sautes de l'interface utilisateur.

ARC propose quelque chose de très différent. D'abord, il ne souffre d'aucun des désavantages de l'exécutif en Objective C du ramasse miettes. ARC est déterministe ; tout le code de gestion de la mémoire est intégré dans l'exécutable et ne change pas à l'exécution. La gestion de mémoire est intégrée directement dans le flux du programme, plutôt que d'être faite par lots, périodiquement. Cela empêche des arrêts dans l'exécution, et peut aussi réduire la hauteur de crue.

La plupart des formes de gestion automatique de la mémoire sont sujettes à une certaine baisse de performance. Pas ARC. Pour compenser l'augmentation possible du nombre des messages de gestion de mémoire générés par ARC, retain et release sont 2,5 fois plus rapides dans Lion ; les pools autorelease vont 6 fois plus vite ; et pour corser le tout, un envoi normal de message Objective C est 33 % plus rapide. De plus, comme c'est le compilateur, et pas le programmeur, qui insère le code de gestion de mémoire, le code retain et release généré n'a pas à ressembler exactement à l' envoi d'un message Objective C normalement compilé. Lse compilateur a une relation beaucoup plus intime avec l'exécutif Objective C, et peut donc optimiser ces opérations d'une façon que le programmeur ne pourrait pas faire (et ne doit pas faire, de toute façon).

Pour terminer, à la différence du ramasse miettes, ARC est un dispositif par unité de compilation. L'utilisation de ARC dans votre application ne signifie pas que chaque bibliothèque que vous liez tournera aussi sour ARC. Cela veut dire que vous n'avez pas à vous soucier si -, oui ou non, chacune des bibliothèques d'Apple fonctionne correctement sous ARC. Apple est la seule à se préoccuper de cela, et peut décider au cas par cas, ce qui doit être compilé avec ARC, et ce qui ne doit pas l'être. Du code ARC et non-ARC peut être mélangé librement.

Le ramasse miettes d'Objective C a cependant un avantage sur ARC. Le ramasseur de miettes peut détecter et récupérer correctement des graphes d'objets avec de cycles dedans. Avec le comptage de références, si un objet A a une référence vers l'objet B, et l'objet B a une référence vers l'objet A, alors, A et B ont tous deux un compte de référence d'au moins 1. Même si aucun autre objet dans toute l'application n'a de référence sur A ou B, A et B ne seront pas désalloués avec ARC parce que tous deux ont pour l'éternité un compte de référence différent de zéro.

ARC réclame que le programmeur gère explicitement ces situations, soit manuellement en cassant les cycles par la suppression d'une ou de plusieurs références, ou en utilisant une autre caractéristique d'objective C appelée "mise à zéro de références faibles". (Une référence faible est une référence qui ne contribue pas au compte de références de l'objet). Par exemple, dans une relation parent/enfant typique, le parent peut avoir une référence sur l'enfant, et l'enfant peut avoir en retour une référence faible sur le parent. Quand l'application ne référence plus le parent ou l'enfant, l'enfant aura un compte de référence de 1 (le parent le référence toujours), mais le parent aura un compte de référence de zéro, et sera donc désalloué. Cela laisse alors l'enfant avec un compte de référence de zéro, et il sera désalloué. Et voilà... pas de fuite de mémoire.

La mise à zéro signifie que les références faibles seront mises à nil quand l'objet qu'elles référencent se trouve désalloué. (Sous ARC, tous les pointeurs sur les objets sont initialement mis à zéro). Dans des circonstance normales, un objet ne doit pas être désalloué s'il y a encore des références qui demeurent sur lui. Mais comme les références faibles ne participent pas au compte de références d'un objet, l'objet peut être désalloué quand des références faibles demeurent sur lui. Quand cela arrive, la mise à zéro automatique des références faibles qui demeurent, les empêche de devenir des pointeurs perdus. (en Objective C, l'envoi d'un message à nil est une no-op).


ARC contre le monde

Venons en maintenant au jeu des 65 536 octets. Est-ce que ARC place Apple sur le même pied que ses concurrents en ce qui concerne l'abstraction du langage de programmation ? La réponse est non, j'en suis navré. ARC prend en compte presque toutes les tâches banales de la gestion de mémoire sous Objective C, mais tout ce qui est en dehors d'objective C reste comme c'était. En plus, ARC fait très peu pour satisfaire cet autre pilier d'une programmation moderne de haut niveau : la sécurité de la mémoire.

Avec tous ses pointeurs qui se mettent tous seuls à zéro, et la désallocation automatique d'objet, Objective C assisté de ARC est toujours un sur-ensemble de C, et les développeurs restent exposés à une seule déréférence d'un mauvais pointeur capable de gribouiller partout dans l'espace de mémoire de l'application. On est loin de langages disponibles sur d'autres plateformes, mobiles ou de bureau, qui disposent du ramasse miettes, de la détection de cycles, d'une mémoire sûre, et parfois même sont typés dynamiquement.

La première chose que révèle ARC, c'est qu'Apple admet qu'il y a une brèche à combler. Elle a choisi d'attaquer par le fruit le plus bas, la seule chose dans l'environnement de développement d'Apple susceptible d'être remarquée comme primitive et dépassée par des programmeurs qui viennent d'autres plateformes, ou même qui sortent tout juste de l'école : la gestion manuelle de la mémoire. Mais en faisant cela, Apple ne voulait sacrifier aucun des avantages historiques d'Objective C. Objective C avec ARC conserve sa compatibilité avec le code existant et les bibliothèques, et reste svelte, excellent, et aussi rapide qu'il la toujours été, plus rapide dans certains cas.

Pour le moment, Apple semble se consacrer à ces deux piliers de plateforme : la compatibilité et la performance. La compatibilité est essentielle pour protéger l'investissement considérable fait par Apple dans ses APIs et ses outils de développement. (Apple est même allée jusqu'à permettre à ARC de tourner sous Snow léopard, bien que sans la mise à zéro des références faibles. La performance reste un avantage compétitif pour les appareils mobiles d'Apple, pas seulement en termes de capacité de réponse de l'interface ou d'animations qui ne bégaient pas, mais aussi pour l'utilisation de l'énergie. Ces ramasse miettes à l'exécution et les machines virtuelles sur les autres plateformes peuvent défaire des caches et maintenir plus de cœurs de CPUs en travail plus longtemps, et plus durement.

Apple peut avoir dansé avec le ramasse miettes à l'exécution, mais elle revient à la maison avec l'automatisation au moment de la compilation. Il n'y a pas d'indicateur plus clair de son implication, que le fait que ARC est maintenant l'option par défaut de tous les nouveaux projets créés sous XCode ; le ramasse miettes ne l'a jamais été.

L'aspect le plus étonnant de ARC, c'est qu'il pourrait annoncer le futur d'Apple. ARC montre qu'Apple cherche à ajouter des restrictions au langage, en échange de la facilité et de la sécurité pour le développeur. Cela implique aussi qu'Apple croit que l'automatisation au moment de la compilation, et l'optimisation sont, sinon préférables, du moins aussi bonnes que des solutions à l'exécution disponibles ailleurs, principalement pour les plateformes mobiles.

Une chose qu'Apple n'envisage apparemment pas dans le futur de ses plateformes est la machine virtuelle traditionnelle pour toutes les raisons définies précédemment : performance, compatibilité, et énergie. Le ramasse miettes à l'exécution est aussi hors jeu pour le moment. (Ce n'est pas qu'Apple croie que le ramasse miettes empêche nécessairement de bonnes performances ; il est seulement mal adapté à Objective C et à Cocoa.)

Ce dont dispose Apple à la place, c'est d'un compilateur traditionnel de compétition construit sur un framework qui supporte beaucoup des mêmes concepts (par exemple bytecode, JIT), mais à un plus bas niveau.

En mettant tout ensemble, il n'est pas difficile d'imaginer un futur où les développeurs Apple écriront du code dans un langage qui gère la mémoire en toute sécurité et qui comprend seulement les aspects de plus haut niveau d'Objective C, mais reste compatible avec les bibliothèques et le code d'Objective C. Cette approche a été décrite comme "Objective C sans C", et on n'en est pas loin. On pourrait y arriver par une série de modifications incrémentales (ARC étant la dernière) qui vont rajouter lentement des caractéristiques optionnelles (mais recommandées), et des restrictions à Objective C, la dernière de ces modifications pouvant être destinée à introduire un "nouveau langage".

Apple a investi beaucoup de temps et de travail en se débarrassant de gcc, pour un compilateur plus rapide et plus puissant. Maintenant que la transition est faite, l'attention d'Apple peut se tourner vers l'addition de caractéristiques innovantes. Les prochaines années de la WWDC pourraient être intéressantes.