Pourquoi l'équipe de LMAX a-t-elle utilisé Java et conçu l'architecture pour éviter à tout prix le GC?

Pourquoi l'équipe de LMAX a-t-elle conçu le disjoncteur LMAX en Java alors que toutes leurs conceptions visent à minimiser l'utilisation du GC? Si l'on ne veut pas que GC s'exécute, alors pourquoi utiliser une langue récupérée?

Leurs optimisations, le niveau de connaissance du matériel et la pensée qu'ils mettent sont tout simplement géniaux mais pourquoi Java?

Je ne suis pas contre Java ou quoi que ce soit, mais pourquoi un langage GC? Pourquoi ne pas utiliser quelque chose comme D ou tout autre langage sans GC mais permet un code efficace? Est-ce que l'équipe est la plus familière avec Java ou Java possède-t-il un avantage unique que je ne vois pas?

Disons qu'ils le développent en utilisant D avec une gestion manuelle de la mémoire, quelle serait la différence? Ils devraient penser à un niveau bas (ce qu'ils sont déjà), mais ils peuvent retirer les meilleures performances du système car il est natif.

Parce qu'il y a une énorme différence entre optimiser les performances et désactiver complètement une sécurité

En réduisant le nombre de GC, leur structure est plus réactive et peut fonctionner (vraisemblablement) plus rapidement. Maintenant, l'optimisation pour le ramasse-miettes ne signifie pas qu'ils ne font jamais de ramasse-miettes. Cela signifie simplement qu'ils le font moins souvent, et quand ils le font, cela fonctionne très rapidement. Ce type d'optimisation comprend:

1. Minimiser le nombre d'objets qui se déplacent vers un espace survivant (c'est-à-dire qui ont survécu à au moins une collecte des ordures) en utilisant de petits objets jetables. Les objets qui se sont déplacés vers l'espace du survivant sont plus difficiles à collecter et une collecte de déchets ici implique parfois de geler toute la JVM.
2. N'allouez pas trop d'objets pour commencer. Cela peut se retourner si vous ne faites pas attention, car les objets de la jeune génération sont super bon marché à allouer et à collecter.
3. Assurez-vous que le nouvel objet pointe vers l'ancien (et non l'inverse) afin que le jeune objet soit facile à collecter, car il n'y a aucune référence à ceux-ci qui entraînera sa conservation.

Lorsque vous désactivez les performances, vous ajustez généralement un "point chaud" très spécifique tout en ignorant le code qui ne s'exécute pas souvent. Si vous faites cela en Java, vous pouvez laisser le garbage collector s'occuper de ces coins sombres (car cela ne fera pas beaucoup de différence) tout en optimisant très soigneusement la zone qui s'exécute en boucle serrée. Vous pouvez donc choisir où vous optimisez et où vous ne le faites pas, et vous pouvez ainsi concentrer vos efforts là où cela compte.

Maintenant, si vous désactivez complètement la récupération de place, vous ne pouvez pas choisir. Vous devez vous débarrasser manuellement de chaque objet, jamais. Cette méthode est appelée au plus une fois par jour? En Java, vous pouvez le laisser faire, car son impact sur les performances est négligeable (il peut être correct de laisser un GC complet se produire chaque mois). En C ++, vous perdez toujours des ressources, vous devez donc prendre soin même de cette méthode obscure. Vous devez donc payer le prix de la gestion des ressources dans chaque partie de votre application, tandis qu'en Java, vous pouvez vous concentrer.

Mais ça empire.

Et si vous avez un bug, disons dans un coin sombre de votre application qui n'est accessible que le lundi à la pleine lune? Java a une forte garantie de sécurité. Il y a peu ou pas de "comportement indéfini". Si vous utilisez quelque chose de mal, une exception est levée, votre programme s'arrête et aucune corruption de données ne se produit. Vous êtes donc presque sûr que rien de mal ne peut se produire sans que vous vous en rendiez compte.

Mais dans quelque chose comme D, vous pouvez avoir un mauvais accès au pointeur, ou un débordement de tampon, et vous pouvez corrompre votre mémoire, mais votre programme ne le saura pas (vous avez désactivé la sécurité, rappelez-vous?) Et continuera à fonctionner avec son incorrect données, et faire des choses assez désagréables et corrompre vos données, et vous ne savez pas, et comme plus de corruption se produit, vos données deviennent de plus en plus erronées, puis soudainement elles se cassent, et c'était dans une application vitale, et une erreur est survenue dans le calcul d'une fusée, et il ne fonctionne pas, et la fusée explose, et mourir quelqu'un, et votre entreprise est dans la première page de tous les journaux et votre patron point de son doigt pour vous dire : « vous êtes l'ingénieur qui a suggéré que nous utilisions D pour optimiser les performances, comment se fait- il que vous n'ayez pas pensé à la sécurité?". Et c'est de ta faute. Tu as tué ces gens avec ta folle tentative de performance.

OK, ok, la plupart du temps c'est beaucoup moins dramatique que ça. Mais même une application critique pour l'entreprise ou simplement une application GPS ou, disons, un site Web gouvernemental de santé peut avoir des conséquences assez négatives si vous avez des bugs. Utiliser un langage qui les empêche complètement ou qui échoue lorsqu'ils surviennent est généralement une très bonne idée.

Il y a un coût à désactiver une sécurité. Devenir natif n'a pas toujours de sens. Parfois, il est beaucoup plus simple et plus sûr d'optimiser un peu un langage sûr pour aller dans une langue où vous pouvez vous tirer une balle dans le pied. L'exactitude et la sécurité dans de nombreux cas l'emportent sur les quelques nano secondes que vous auriez supprimées en éliminant complètement le GC. Disruptor peut être utilisé dans ces situations, donc je pense que LMAX-Exchange a fait le bon appel.

Mais qu'en est-il de D en particulier? Vous avez un GC si vous le souhaitez pour les coins sombres, et le sous-ensemble SafeD (que je ne connaissais pas avant l'édition) supprime le comportement indéfini (si vous vous souvenez de l'utiliser!).

Eh bien, dans ce cas, c'est une simple question de maturité. L'écosystème Java est plein d'outils bien écrits et de bibliothèques matures (mieux pour le développement). Beaucoup plus de développeurs connaissent Java que D (mieux pour la maintenance). Choisir une langue nouvelle et moins populaire pour quelque chose d'aussi critique qu'une application financière n'aurait pas été une bonne idée. Avec un langage moins connu, si vous avez un problème, peu de gens peuvent vous aider, et les bibliothèques que vous trouvez ont tendance à avoir plus de bugs car elles ont été exposées à moins de personnes.

Donc, mon dernier point tient toujours: si vous voulez éviter des problèmes aux conséquences désastreuses, restez avec des choix sûrs. A ce stade de la vie de D, ses clients sont les petites start-ups prêtes à prendre des risques fous. Si un problème peut coûter des millions, il vaut mieux rester plus loin dans la courbe en cloche de l' innovation .

Il semble que la raison pour laquelle il est écrit en Java est qu'ils possèdent une expertise Java en interne et il a probablement été écrit (bien qu'il soit encore en développement actif) avant que C ++ n'agisse avec C ++ 0x / 11.

Leur code n'est vraiment que Java par leur nom, ils utilisent un peu sun.misc.Unsafe, ce qui défait le point de Java et la sécurité est censée donner. J'ai écrit un port C ++ du Disruptor et il surpasse le code Java qu'ils livrent (je n'ai pas passé beaucoup de temps à régler la JVM).

Cela dit, les principes que le perturbateur suit ne sont pas spécifiques au langage, par exemple Ne vous attendez pas à un code C ++ à faible latence qui alloue ou libère du tas.

Cette question énonce une prémisse incorrecte comme fait, puis fait un argument à propos de cette prémisse incorrecte.

Permet de creuser dans cela .. "tous leurs points de conception pour minimiser l'utilisation du GC" - n'est tout simplement pas vrai. L'innovation dans le disrupteur a peu à voir avec GC. Le perturbateur fonctionne parce que sa conception considère intelligemment le fonctionnement des ordinateurs modernes - quelque chose de beaucoup moins courant que ce à quoi on pourrait s'attendre. Voir le discours de Cliff Click http://www.azulsystems.com/events/javaone_2009/session/2009_J1_HardwareCrashCourse.pdf pour une discussion.

Il est bien connu que LMax est client d'Azul. Je sais de première main qu'avec les GC Azul, il n'y a tout simplement pas de problème - même avec des tas de 175 Go.

Ils devraient penser à bas niveau

Ci-dessus représente la moitié de la réponse que vous recherchez. Vous pouvez trouver une autre moitié pour compléter le raisonnement pas plus loin que dans le blog LMAX :

Bien que très efficace, il peut conduire à un certain nombre d'erreurs car il est très facile de visser ...

Comme admis par les développeurs LMAX, un code comme celui-ci peut être assez difficile à développer, à comprendre et à déboguer - même en Java. Aller plus bas que ce qu'ils sont maintenant ne fera qu'exacerber ce problème, comme le souligne un article de Wikipedia sur les langages de programmation de bas niveau :

Un programme écrit dans un langage de bas niveau peut être exécuté très rapidement et avec une très petite empreinte mémoire; un programme équivalent dans une langue de haut niveau sera plus lourd. Les langages de bas niveau sont simples, mais sont considérés comme difficiles à utiliser, en raison des nombreux détails techniques dont il faut se souvenir .

Par comparaison, un langage de programmation de haut niveau isole la sémantique d'exécution d'une architecture informatique de la spécification du programme, ce qui simplifie le développement ...

Si vous utilisez Java comme langage de syntaxe et évitez ses bibliothèques JDK, il peut être aussi rapide qu'un langage non GC compilé. GC n'est pas adapté aux systèmes en temps réel, mais il est possible de développer des systèmes en Java qui ne laissent aucun déchet. Par conséquent, le GC ne se déclenche jamais.

Nous pensons que le langage et la plate-forme Java présentent de nombreux avantages par rapport à C / C ++ et nous avons développé et comparé certains composants Java à très faible latence pour le prouver. Nous parlons des techniques pour le faire dans cet article: Développement Java sans GC .

LMAX est une bibliothèque de messagerie inter-threads haute performance.

Pour être utile, quelqu'un d'autre doit écrire le code pour que chaque thread fasse un travail utile. Étant donné que le code est le plus susceptible d'être en Java ou en C #, il y a très peu de choix de langage qui s'interfacent bien avec eux.

L'utilisation de C ou C ++ n'est pas une bonne option, sauf si vous souhaitez limiter vos utilisateurs à un seul système d'exploitation, car aucun modèle de thread n'est défini en eux.

Java est la norme pour beaucoup de développement de logiciels de nos jours, donc à moins que vous n'ayez une bonne raison, il a tendance à être le meilleur choix. (Quand à Rome faites comme les Romains…)

L'écriture de logiciels Haute Performance en Java (ou C #) se fait souvent pour prouver un point…