OCTO - 2013 - Devoxx - la mort du gc

893 views

Published on

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
893
On SlideShare
0
From Embeds
0
Number of Embeds
2
Actions
Shares
0
Downloads
7
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

OCTO - 2013 - Devoxx - la mort du gc

  1. 1. La mort du GC ?21h - 22h - Salle E. Fitzgerald & L. Armstrong
  2. 2. La mort prochaine du GC ? Philippe PRADOS OCTO - Consultant @pprados – www.prados.fr 27 au 29 mars 2013
  3. 3. Philippe PRADOS Conférences • Java User Group • Paris Android User Group • DevFest (vidéo) • Solution Linux • SSTIC Plus de 100 articles dans • Linux Mag • Programmez • 01 • MISC • … Philippe PRADOS Deux livres @pprados
  4. 4. Petit rappel – Le GC c’est quoi ? • Algorithme qui supprime les objets inutiles. • Nécessite une période d’arrêt-du-monde
  5. 5. Ma conviction Le ramasse-miettes ne sera plus LA solution
  6. 6. La mort prochaine du GC ? Intuitions Preuves et constat Nouvelles stratégies Solutions alternatives Prospectives Polémiquons !
  7. 7. Intuitions 27 au 29 mars 2013
  8. 8. G1 nécessaire Le nouvel algo de GC (G1) est voir jHiccup de Azul nécessaire… …mais limité
  9. 9. 64 bits moins rapide • 15% moins rapide que les 32 bits voir jHiccup de Azul • Un artifice : le mode pseudo-64 bits
  10. 10. Mémoire hors heap – déjà ? -XX:MaxDirectMemorySize=2G
  11. 11. Les DB in memory utilisent hors heap > 8 Go problématique http://goo.gl/zsrXC
  12. 12. Loi de Moore aux limites Fin en 2018 ? http://goo.gl/MHYn8
  13. 13. @deprecated GC Objective-C Automatic Counting Reference
  14. 14. Est-ce un problème ?
  15. 15. Preuves et constat 27 au 29 mars 2013
  16. 16. Puissance / Volume s’inverse bientôt Puissance processeur Volume à traiter
  17. 17. Il faut dépasser les limites • Limites I/O • Augmentation de mémoire
  18. 18. Avant 1981: 16 bits d’adresse • 2 octets par adresse 65.536 cases mémoire tout compris • Processeurs 8 bits 8 bits 8 bits • Processeurs lents • Impossible d’utiliser un GC 16 bits • Mémoire à la main
  19. 19. Avant 1986 : 24 bits d’adresse • 2 x 16 bits = 4 octets par 16 Mo adresse • Processeurs 16 bits 24 bits • Processeurs lents • Impossible d’utiliser un GC • Mémoire à la main
  20. 20. Avant 2001 : 32 bits d’adresse – Cool • 4 octets 4 Go théorique • Processeurs très rapides 32 bits • Super ! On peut utiliser un GC • La mémoire est gérée automatiquement
  21. 21. Maintenant: 64 bits d’adresse • Maintenant, nous avons 256 tébioctets - 240 un problème • 8 octets • Processeurs aux limites 64 bits Pour le moment, la mémoire de base permet de tenir
  22. 22. Coût des mémoires en baisse Historical cost of computer memory and storage • All in memory possible • 1980 : 5000$/MB Évite l’ajout d’un nœud 2010 : 100$/MB
  23. 23. Problèmes avec « All in memory » et GC Objectif: • Un accès direct aux objets persistants • Algorithmes non orientés « secteur » En réalité: • Objets hors-heap • Accès via sérialisation/désérialisation • Accès orientés « zone mémoire » Heap avec GC Hors-Heap sans GC
  24. 24. All-in-memory contre DB sur SSD ? • Mort des disques magnétiques dans 5 ans • Swapfile sur SSD • Indexations orienté objet en mémoire. • files systèmes avec allocateur « mémoire »
  25. 25. Chiffre 2008 : avec 3,5 Terabyte,l’arrêt-du-monde dure 30 secondes
  26. 26. Absurdité économique ? • Un cœur pour le GC = un étage sur quatre ! Économie en développement •pas toujours compensée
  27. 27. Comment retarder l’échéance ?
  28. 28. Nouvelle stratégies?
  29. 29. Le GC victime de malédiction Plus on augmente la mémoire, plus on dégrade les performances
  30. 30. Segmenter, segmenter, segmenter la mémoire Réduire le volume traité par le GC
  31. 31. Application interactives : moins de mémoire • Plusieurs JVM par nœud • Plusieurs VM par nœud • Abandon des threads • « share nothing » • GC par thread dans la JVM ? • Agents • GC par Classloader ?
  32. 32. Application « memory based » : hors heap• Utiliser du hors-heap• Langage sans ramasse-miettes (C/C++, Objectif-C, etc.)
  33. 33. Plus radical : faute de page • GC sans arrêt du monde (Azul) • Patch/module kernel (que sur *nix !) • Pendant le GC: • Pages invalide • Capture des faute de pages • Patch l’adresse dans l’appelant et relance • Page déclarée valide
  34. 34. Solutions alternatives 27 au 29 mars 2013
  35. 35. Augmenter la sémantique pour les pointeurs Immuable Un pointeur est : • Une relation ou une agrégation 1 vers un objet immuable Agrégation • simple Une agrégation simple • Une agrégation partagée 1 • Immuable Une relation • Forte ? • Faible ? 1 Immuable
  36. 36. Et les autres langages ? • C++11 : shared_ptr, weak_ptr, unique_ptr et les rvalue_references. • « Automatic Counteur Reference » (Objective-C). • Acteur (ER-Lang, Go, Scala) • Isolation totale (Javascript ou Dart) • Programmation fonctionnelle (Hashkell, Closure, Scala, etc.)
  37. 37. Prospectives 27 au 29 mars 2013
  38. 38. Où allons nous ? Puissances DEFINITIVEMENT à saturation : • ++Volume avec puissance égale Big-memory : • Sémantique forete des pointeurs • Libération déterministe. Multiplication des CPU : • Agents distribués. • Objets immuables. Réseau : • Peer-to-peer
  39. 39. Où allons nous ? La mémoire de masse • Sera statique • Avec de gros volumes Montage de la mémoire statique en RAM • Plusieurs téra-octets en ligne et persistant !
  40. 40. Et pour nos JVM ? • Java 9 ou 10 saura découper la mémoire en tranche pour aider le GC ? • Hors-heap sera la seule disponible ? • @deprecated GC comme pour Objectif-C ? • OS pour GC ? • Changer de langage? • Langages fonctionnels et à agents ?
  41. 41. Qu’en penser ? Deux solutions : • « Il est fort probable que cela arrivera » • « Ce type est fou, il n’y a pas problème » Rendez-vous dans 5 ans (ou avant)
  42. 42. Rappel des signaux faibles• Intel prédit la fin de l’augmentation • > 8 Go => Dégradation de puissance des processeurs pour 2018 • @deprecated GC Objective-C !• JVM 64 bits plus lent• G1 est NECESSAIRE• -XX:MaxDirectMemorySize=2G
  43. 43. Polémiquez !!!

×