Orientations pour le gestionnaire de mémoire ARC sous Delphi
Avec l'arrive de la version 10.3, les équipes R&D et PM officialises la nouvelle orientation en matière de gestion de mémoire.
Il y a quelques années, lorsque Embarcadero a commencé à créer des nouveaux compilateurs Delphi pour les autres plateformes que Windows, il y a eut beaucoup de discussions sur au combien le nouveau Delphi devait être compatible avec le langage actuel, en termes de fonctionnalités de bases et de perception générale du langage. Au final, la décision a été de garder la plus grande compatibilité avec quelques améliorations audacieuses pour attirer de nouvelles générations de développeurs.
Qu'est que le comptage automatique de références ?
(objets mutuellement référencés avec une référence faible)
L'un des changements à ce sujet a été la décision d'adopter un nouveau modèle de gestion de la mémoire pour les plates-formes mobiles, à la suite de ce que Apple préconisait déjà comme modèle de mémoire iOS: le comptage automatique des références ou ARC. Sur un appareil à mémoire limitée, tel qu'un téléphone portable utilisant le ramasse miettes (Garbage Collector), est souvent considéré comme un problème (au final, vous consommez beaucoup plus de mémoire que ce dont vous avez besoin, et cela affecte également la durée de vie de la batterie) et ARC offre un modèle de gestion de la mémoire simplifié, plus simple à utiliser dans des scénarios simples, entièrement déterministes et robustes.
C'est pourquoi Delphi a choisi ce même modèle, en élargissant le modèle déjà disponible depuis longtemps pour les interfaces, en le rendant plus puissant avec des références faibles et non sécurisées, et en l'élargissant aux variables d'objet simples. Ce modèle offre des avantages significatifs, et l'une des idées originales était de l'étendre au langage Delphi sur toutes les plateformes.
Les inconvénients de ARC
(références entremêlées faibles et fortes)
Quelques années après le déploiement de ce projet, nous en voyons toujours les avantages, mais nous avons une idée beaucoup plus claire des inconvénients du modèle ARC et de son effet sur son utilisation par défaut également dans les applications Windows et VCL.
Nous avons longtemps considéré la gestion de la mémoire ARC comme une amélioration par rapport au modèle Delphi traditionnel, car elle supprime et simplifie une partie de la gestion de la mémoire. Cependant, nous avons appris lors de la construction et de la maintenance de nos grandes bibliothèques et en discutant avec les clients sur des bases de codes complexes que, même si ARC a belle allure sur papier, pour des variables locales et les scénarios plus simples, il pose souvent beaucoup de problèmes pour les scénarios complexes. De plus, le modèle de propriété de TComponent sur lequel toutes nos bibliothèques sont centrées est en contradiction avec ARC, ce qui complique l'utilisation de ARC pour les bibliothèques de composants existantes.
Nous aurions pu décider d’utiliser également «tout ARC» sous Windows, mais cela aurait entraîné une rupture importante avec les applications et composants existants, causant bien plus de problèmes que la migration Unicode que nous avons effectuée par le passé - en raison de la forte demande d'un bon support international et le fait que les systèmes d'exploitation sous-jacents (notamment Windows) étaient également Unicode.
Nous avons eu de nombreuses demandes pour rendre ARC facultatif, mais un objet ARC compatible ne coexistera pas facilement avec un objet non compatible ARC, et nous aurions besoin de conteneurs pour les deux types d’objets et rendrait impossible leur mélange. Cela aboutirait à un scénario extrêmement complexe. Mélanger ARC et non-ARC n’est pas une solution viable, mais conserver différents modèles de mémoire sur différentes plates-formes finit par faire échec à l’idée même de «source unique, multi-plate-forme», qui est l’un des principes fondamentaux du focus actuel de Delphi côté serveur (Windows et Linux) et côté client sur toutes les plateformes pour lesquelles vous pouvez créer des applications FireMonkey.
Un autre angle important est que l’ARC a un coût d’exécution. Bien que les choses puissent être optimisées et améliorées, à la fin, la gestion automatique n’est pas totalement gratuite. Alors que le ramasse miettes a un coût (très élevé) lorsqu’il démarre, ARC a un coût sur toute la durée de vie des objets et leur interaction (sauf si vous utilisez prudemment const pour tous les paramètres transmis). Un effet positif de la désactivation d'ARC est une amélioration mesurable des performances. Enfin, ARC dans Delphi est un peu en contradiction avec le côté C ++ du produit, qui fait partie intégrante de RAD Studio.
Le nouveau plan: suppression progressive de l'ARC
(utilisation des interfaces sous Delphi)
En tenant compte de toutes ces considérations et après de longues discussions internes impliquant également des partenaires et des développeurs externes, nous sommes arrivés à la conclusion que la meilleure solution consistait à remplacer le modèle ARC par une solution de gestion de la mémoire par défaut et à compenser sa perte. avec d'autres alternatives.
Concrètement, le compilateur Linux 64 bits de la version 10.3 de Rio offrira la gestion de la mémoire Delphi traditionnelle des plates-formes Windows, ce qui rendra les codes côté serveur Windows et Linux totalement équivalents, du moins en termes de langage Delphi et de gestion de la mémoire.
Le plan à venir est de ne pas adopter ARC pour la prochaine plate-forme macOS 64 bits (toutes les plates-formes de bureau sont et resteront sur le modèle non ARC) et de désactiver également ARC pour les plates-formes mobiles à l'avenir (probablement avec la prochaine version majeure après 10.3). Notez que, dans Rio 10.3, les compilateurs mobiles restent avec ARC activé, exactement comme dans 10.2.
Quoi d'autre pour la gestion moderne de la mémoire ?
(Source: https://pixabay.com/photo-1751201/)
Nous pensons toujours que la gestion de la mémoire comptée par référence est pertinente, mais plutôt que d’introduire un nouveau mécanisme, nous préférons utiliser et augmenter le modèle compté de référence existant utilisé par les interfaces et les chaînes dans Delphi. C'est le cas depuis longtemps. Les références d'interface et des références d'objet pointant sur le même objet peuvent causer des problèmes si elles ne sont pas gérées correctement, mais c'est quelque chose que la plupart des développeurs Delphi savent déjà gérer et il existe de nombreux documents sur le sujet.
Les références d'interface ont été récemment étendues avec des références faibles (weak) et même des références non sécurisées (unsafe). Ces options supplémentaires augmentent considérablement la puissance et la flexibilité de «ARC pour les interfaces». En d'autres termes, pendant que nous allons supprimer ARC pour les références d'objet, ARC pour les références d'interface est une fonctionnalité du langage qui a été et restera disponible.
De plus, nous souhaitons améliorer et simplifier la gestion de la durée de vie (et de la gestion de la mémoire) des objets locaux à vie courte ayant des références de pile. Nous n'allons pas introduire cette fonctionnalité dans la version 10.3, mais nous étudions activement cette possibilité et nous pouvons partiellement la mettre en œuvre par les développeurs en exploitant les structures managées (managed records) (une nouvelle fonctionnalité de langage dans la version 10.3).
Conclusion
((Suivi des fuites de mémoire simplifié))
Bien que nous comprenions que cette modification des plans effectuée il y a quelques années peut être une surprise et affecter le code existant, les développeurs mécontents du modèle ARC, prenant en charge plusieurs modèles sur différentes plates-formes et de leur perte de performances par rapport à la gestion de la mémoire native , vont probablement apprécier la décision.
La feuille de route de RAD Studio offre d'autres moyens de simplifier encore davantage la gestion de la mémoire Delphi, mais l'ensemble actuel de fonctionnalités (interfaces avec comptage de références et prise en charge des références faibles et non sécurisées, le modèle de propriétaire (owner) de composant et les pratiques courantes standard) fournit déjà un bon cadre pour réduire les soucis de la gestion manuelle de la mémoire pour les développeurs Delphi.
En fin de compte, il n’existe pas de solution parfaite pour la gestion de la mémoire dans les langages de programmation, car les langages automatiques ont leurs inconvénients et le mode manuel est (et bien) manuel. Delphi a eu un très bon équilibre dans le passé, qui se poursuit aujourd'hui et ne fera que s'améliorera que dans le futur.
traduction par Paul TOTH - aidé de Google - de l'article de Marco.
Date de dernière modification : 26/10/2018