OCTO - 2013 - Devoxx - la mort du gc

  • 446 views
Uploaded on

 

  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
    Be the first to like this
No Downloads

Views

Total Views
446
On Slideshare
0
From Embeds
0
Number of Embeds
0

Actions

Shares
Downloads
5
Comments
0
Likes
0

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 1. La mort du GC ?21h - 22h - Salle E. Fitzgerald & L. Armstrong
  • 2. La mort prochaine du GC ? Philippe PRADOS OCTO - Consultant @pprados – www.prados.fr 27 au 29 mars 2013
  • 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. Petit rappel – Le GC c’est quoi ? • Algorithme qui supprime les objets inutiles. • Nécessite une période d’arrêt-du-monde
  • 5. Ma conviction Le ramasse-miettes ne sera plus LA solution
  • 6. La mort prochaine du GC ? Intuitions Preuves et constat Nouvelles stratégies Solutions alternatives Prospectives Polémiquons !
  • 7. Intuitions 27 au 29 mars 2013
  • 8. G1 nécessaire Le nouvel algo de GC (G1) est voir jHiccup de Azul nécessaire… …mais limité
  • 9. 64 bits moins rapide • 15% moins rapide que les 32 bits voir jHiccup de Azul • Un artifice : le mode pseudo-64 bits
  • 10. Mémoire hors heap – déjà ? -XX:MaxDirectMemorySize=2G
  • 11. Les DB in memory utilisent hors heap > 8 Go problématique http://goo.gl/zsrXC
  • 12. Loi de Moore aux limites Fin en 2018 ? http://goo.gl/MHYn8
  • 13. @deprecated GC Objective-C Automatic Counting Reference
  • 14. Est-ce un problème ?
  • 15. Preuves et constat 27 au 29 mars 2013
  • 16. Puissance / Volume s’inverse bientôt Puissance processeur Volume à traiter
  • 17. Il faut dépasser les limites • Limites I/O • Augmentation de mémoire
  • 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. 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. 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. 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. 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. 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. 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. Chiffre 2008 : avec 3,5 Terabyte,l’arrêt-du-monde dure 30 secondes
  • 26. Absurdité économique ? • Un cœur pour le GC = un étage sur quatre ! Économie en développement •pas toujours compensée
  • 27. Comment retarder l’échéance ?
  • 28. Nouvelle stratégies?
  • 29. Le GC victime de malédiction Plus on augmente la mémoire, plus on dégrade les performances
  • 30. Segmenter, segmenter, segmenter la mémoire Réduire le volume traité par le GC
  • 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. Application « memory based » : hors heap• Utiliser du hors-heap• Langage sans ramasse-miettes (C/C++, Objectif-C, etc.)
  • 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. Solutions alternatives 27 au 29 mars 2013
  • 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. 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. Prospectives 27 au 29 mars 2013
  • 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. 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. 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. 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. 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. Polémiquez !!!