21h - 22h - Salle E. Fitzgerald & L. Armstrong

La mort du GC ?

27 au 29 mars 2013

La mort prochaine du GC ?

Philippe PRADOSOCTO - Consultant

@pprados – www.prados.fr

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

• …

Deux livres @pprados

Philippe PRADOS

Petit rappel – Le GC c’est quoi ?

• Algorithme qui supprime les objets inutiles.• Nécessite une période d’arrêt-du-monde

Ma conviction

Le ramasse-miettes ne sera

plus LA solution

La mort prochaine du GC ?

IntuitionsPreuves et constatNouvelles stratégiesSolutions alternativesProspectives

Polémiquons !

27 au 29 mars 2013

Intuitions

G1 nécessaire

Le nouvel algo de GC (G1) est nécessaire…

…mais limité

voir jHiccup de Azul

64 bits moins rapide

•15% moins rapide que les 32 bits

•Un artifice : le mode pseudo-64 bits

voir jHiccup de Azul

Mémoire hors heap – déjà ?

-XX:MaxDirectMemorySize=2G

?!

Les DB in memory utilisent hors heap

> 8 Go problématique

http://goo.gl/zsrXC

Loi de Moore aux limites

Fin en 2018 ?

http://goo.gl/MHYn8

@deprecated GC Objective-C

Automatic Counting Reference

Est-ce un problème ?

27 au 29 mars 2013

Preuves et constat

Puissance / Volume s’inverse bientôt

Puissance processeur

Volume à traiter

2015 ? 2020 ?

Il faut dépasser les limites

•Limites I/O

•Augmentation de mémoire

Avant 1981: 16 bits d’adresse

•2 octets par adresse

•Processeurs 8 bits

•Processeurs lents• Impossible d’utiliser un GC

•Mémoire à la main

8 bits 8 bits

16 bits

65.536 cases mémoire tout compris

Avant 1986 : 24 bits d’adresse

•2 x 16 bits = 4 octets par adresse

•Processeurs 16 bits

•Processeurs lents• Impossible d’utiliser un GC

•Mémoire à la main

24 bits

16 Mo

Avant 2001 : 32 bits d’adresse – Cool

•4 octets

•Processeurs très rapides•Super ! On peut utiliser un

GC

•La mémoire est gérée automatiquement

32 bits

4 Go théorique

Maintenant: 64 bits d’adresse

•Maintenant, nous avons un problème•8 octets

•Processeurs aux limites 64 bits

Pour le moment, la mémoire de base permet de tenir

256 tébioctets - 240

Coût des mémoires en baisse

• All in memory possible

• Évite l’ajout d’un nœud

Historical cost of computer memory and storage

1980 : 5000$/MB

2010 : 100$/MB

Hors-Heap sans GCHeap avec GC

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 »

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 »

Chiffre 2008 : avec 3,5 Terabyte,l’arrêt-du-monde dure 30 secondes

Absurdité économique ?

•Un cœur pour le GC = un étage sur quatre !

Économie en développement

•pas toujours compensée

Comment retarder l’échéance ?

Nouvelle stratégies?

Le GC victime de malédiction

Plus on augmente la mémoire,plus on dégrade les performances

Segmenter, segmenter, segmenter la mémoire

Réduire le volume traité par le GC

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 ?

Application « memory based » : hors heap

•Utiliser du hors-heap

•Langage sans ramasse-miettes (C/C++, Objectif-C, etc.)

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

27 au 29 mars 2013

Solutions alternatives

Un pointeur est :•Une relation ou une agrégation

vers un objet immuable

•Une agrégation simple

•Une agrégation partagée

•Une relation

• Forte ?

• Faible ?

Augmenter la sémantique pour les pointeurs

1

Immuable

Agrégation simple

1

Immuable

1

Immuable

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.)

27 au 29 mars 2013

Prospectives

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

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 !

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 ?

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)

Rappel des signaux faibles

• Intel prédit la fin de l’augmentation de puissance des processeurs pour 2018

• JVM 64 bits plus lent

•G1 est NECESSAIRE

• -XX:MaxDirectMemorySize=2G

•> 8 Go => Dégradation

•@deprecated GC Objective-C !

Polémiquez !!!