Discussion :

[Idelways]

BigMemory résoud-t-il le « problème universel » de Java ?
Terracotta sort une solution aux limitations du ramasse-miettes du langage



La société Terracotta, spécialiste du développement open-source s'attaque aux limitations de mémoire imposées aux applications Java.

L'entreprise décrit sa solution, baptisée « BigMemory » et disponible en bêta depuis hier comme une avancée majeure pour résoudre le "problème universel" du ramasse-miettes Java.

La solution est proposée sous forme de module pour « Enterprise EhCache », un gestionnaire de cache développé par Terracotta.

Compatible avec la machine virtuelle Java, BigMemory délivre un cache séparé afin de libérer les applications Java des limitations de mémoire imposées par le ramasse-miettes.
Une empreinte mémoire plus importante est dès lors allouée aux applications.

Pour rappel, le ramasse-miettes (en anglais Garbage Collector) est un mécanisme qui libère automatiquement les cases mémoire occupées par un objet quand plus aucune référence n'y pointe.

Le développeur n'a donc pas à s'occuper de la gestion de la mémoire comme dans d'autres langages, ce qui évite les fuites de mémoire et de nombreux problèmes.

Mais selon Terracotta, le ramasse-miettes est le "talon d'Achiles" des applications Java, pénalisant les performances des applications et limitant l'accès aux données.

"Java est coincé dans le monde des petites quantités de mémoire à cause du ramasse-miette" estime Mike Allen, directeur de la gestion des produits à Terracotta.

Les avantages affichés par Terracotta sont :

• L'augmentation de la quantité de mémoire utilisable, permettant aux applications de mettre en cache 64GB ou plus dans un dépôt non-accessible au passages du ramasse-miettes.
• Les performances des applications seraient améliorées en tournant sur moins de machines virtuelles et avec plus de cache
• Eliminer les réglages et des solutions de contournement inefficaces destinées à optimiser le fonctionnement du ramasse-miettes

Reste à savoir si BigMemory arrivera à se faire une place parmi les nombreuses solutions de contournement déjà existantes.


Pour participer à la bêta privée de BigMemory, une inscription est requise, le produit sera publiquement lancé en Octobre.

Source : le site de Terracota, Inc

Et vous ?

Êtes-vous pour ou contre le ramasse-miettes de Java ?
Que pensez-vous de BigMemory ?
Quelle solution utilisez-vous pour contourner ce problème ? Et quelles sont ses limitations ?

[Florian Goo]

Le développeur n'a donc pas s'occuper de la gestion de la mémoire comme dans d'autres langages, ce qui évite les fuites de mémoire et de nombreux problèmes.

Il faut arrêter de répandre cette fausse vérité.
Il est tout à fait possible d'avoir des fuites de mémoire en Java (dépendances cycliques), d'où l'existence des WeakReference.
Un développeur qui ne se soucie pas de la gestion de la mémoire est un piètre développeur…

[phryos]

Il faut arrêter de répandre cette fausse vérité.
Il est tout à fait possible d'avoir des fuites de mémoire en Java (dépendances cycliques), d'où l'existence des WeakReference.
Un développeur qui ne se soucie pas de la gestion de la mémoire est un piètre développeur…

+10

Tant que l'on a pas fait du profilage, on a pas appris toutes les subtilités de java et du coup on se rend compte de toutes les c......ries que l'on a développé.

[gmatta]

+10

Tant que l'on a pas fait du profilage, on a pas appris toutes les subtilités de java et du coup on se rend compte de toutes les c......ries que l'on a développé.

Le problème c'est que lorsqu'on nous présente Java à l'école on nous dit "la mémoire c'est Java qui gère, pas besoin de s'en faire".
Forcément quand tu apprends le profilage au boulot...tout de suite tu as un choc !

[Uther]

Il faut arrêter de répandre cette fausse vérité.
Il est tout à fait possible d'avoir des fuites de mémoire en Java (dépendances cycliques), d'où l'existence des WeakReference.
Un développeur qui ne se soucie pas de la gestion de la mémoire est un piètre développeur…

Certes il ne faut pas faire n'importe quoi avec la mémoire, mais le GC simplifie énormément les choses. Il s'agit de s'assurer de ne pas garder de référence inutiles, ce qui est quand même bien plus simple que ce qui se fait dans des langages comme le C++ par exemple.

Le GC sait fort heureusement gérer les dépendances cycliques. Si ce n'était pas le cas autant le jeter direct à la poubelle.

[Julien Bodin]

+10

Tant que l'on a pas fait du profilage, on a pas appris toutes les subtilités de java et du coup on se rend compte de toutes les c......ries que l'on a développé.

M'en parle pas... je suis en plein dans cette phase

Mais il est vrai que certaines fois il est confortable d'avoir beaucoup de ram à disposition.
Par exemple dans mon application je dois permettre à un utilisateur de trouver rapidement un enregistrement (une ligne dans un tableau) et pour celà j'ai plusieurs filtres qui concernent certaines colonnes du tableau et ils effacent à la volée les lignes qui ne correspondent pas aux critères.
Le tri en "live" permet de trouver plus facilement un enregistrement et c'est un vrai plus perçu par l'utilisateur (je n'aurais peut-être pas dû les y habituer ). Le hic c'est qu'il faut charger l'ensemble des enregistrements en mémoire. Pour moi, ces 20 000 enregistrements + les mécanismes de filtrage représentent pas loin de 40Mo en RAM.

J'utilise déjà EhCache (de Terracotta) et je limite le nombre d'enregistrements en mémoire, le reste étant stocké sur le disque mais du coup les performances sont fortement dégradées si je dois accéder à un grand nombre d'enregistrement en même temps (typiquement l'affichage dans le tableau), quand c'est sur un accès aléatoire à une fiche en particulier c'est rapide.

[lequebecois79]

azul propose des solutions pour ça depuis belle lurettes...
http://www.azulsystems.com/

[Florian Goo]

Certes il ne faut pas faire n'importe quoi avec la mémoire, mais le GC simplifie énormément les choses. Il s'agit de s'assurer de ne pas garder de référence inutiles, ce qui est quand même bien plus simple que ce qui se fait dans des langages comme le C++ par exemple.

Le GC sait fort heureusement gérer les dépendances cycliques. Si ce n'était pas le cas autant le jeter direct à la poubelle.

En C++ il y a les smart pointers, c'est pas plus compliqué. Mais ce n'est pas le sujet, on ne va pas refaire un Nième troll Java vs C++ .

Et effectivement, au temps pour moi, les dépendances cycliques ne font pas partie des cas qui causent des fuites mémoire en Java. Plus d'infos ici : http://gfx.developpez.com/tutoriel/j...rence-memoire/
Cela dit, ça n'enlève en rien l'importance pour un développeur d'être conscient de la gestion de la mémoire, même en Java.

[GCSX_]

Et plutôt que de dépenser des fortunes en cherchant à le contourner, pourquoi ne pas optimiser le GC?

[bouye]

L'ennui c'est que Sun a passé une décade à optimiser le GC et que malgré les optimisation apportées à Java 1.5 on se tape encore de OutOfMemoryError et on doit faire des allocations harcodées de RAM au lancement de la JVM dans bien des cas.

J'avoue que ça aurait été là un des rares points interressant si IBM avait racheté Sun : en effet, du temps de Java 1.3 et 1.4, la JVM cliente d'IBM avait toujours eut un GC et une allocation de la mémoire bien plus performante que celle de Sun. Ça aurait été interressant de voir leur technologie intégrée au Java mainstream (la JVM d'IBM pour Windows n'a jamais été la plus répandue du marché).

Maintenant j'ignore totalement si Oracle a aussi développé son propre GC et technologies natives aux platformes et, si c'est le cas, j'imagine qu'on ne verra pas leur intégration avant au moins Java 7.

[Uther]

En C++ il y a les smart pointers, c'est pas plus compliqué.

C'est difficile de comparer les smart pointers en C++ au GC en Java:
- Les smart pointers ne sont font pas partie du langage même.
- Il y a plusieurs types de "smart pointers" au fonctionnement différent et il faut bien être conscient de leur mode de fonctionnement pour éviter les bêtises.
- Le seul type de pointeur intelligent actuellement présent dans la bibliothèque standard n'est pas très "smart".

Bref les smart pointers, c'est bien et ça peut être efficace, mais c'est loin d'être aussi simple que le GC de Java.

[tchize_]

maintenant le problème de base n'est pas la mémoire (java sur un OS 64bits peut monter très haut en mémoire allouée) mais le fait que, pour fonctionner correctement, le GC doit traverser toute la mémoire régulièrement. Donc plus il y a de mémoire à scanner, plus le GC sera lent. De plus, il empêche, du coup, l'OS de mettre en swap les parties mémoire peu utilisés, puisque le GC utilise tout .

Sur papier, cette solution permettrait justement de garder un GC rapide (ne doit gérer que quelques centaines de M de mémoire) tout en gardant un cache en mémoire plutôt que sur disque (évite les pertes au niveau IO). Cependant, il faut voir si le gain en Perfs du GC compense ou non la perte de temps du au transfert d'objet de et vers le cache.

[Elendhil]

Et avec les processeurs multi-coeurs est-ce réellement un problème ?

Est-ce que le GC réagi différemment en présence d'un serveur multi-coeurs ?

Par exemple je sais pas , partager l'algo de libération de la mémoire en plusieurs threads pour libérer plus vite ou alors sur plusieurs coeurs un servirait exclusivement au GC ?

[tchize_]

Le GC n'utilise qu'un seul thread. Par rapport au multi-coeurs, il y a des systèmes mis en place pour éviter que le travail du GC ne bloque les autres cœurs, mais c'est tout. Les algorithmes du GC sont difficilement parallélisables, puisqu'ils recherchent une info globale. De plus, avoir 2 cœurs plutôt qu'un qui scanne la mémoire, le problème resterait fondamentalement le même. Ce sont les temps d'accès à la mémoire le goulot d'étranglement, pas la puissance de calcul.

[pseudocode]

le GC n'utilise qu'un seul thread. Par rapport au multi-coeurs, il ya des systèmes mis en place pour éviter que le travail du GC ne bloque les autres coeurs, mais c'est tout. Les algos du Gc sont difficilement parallelisables, puisqu'il recherche une info globale. De plus, avoir 2 coeurs plutot qu'un qui scanne la mémoire, le problème resterait fondamentalement le même. Ce sont les temps d'accès à la mémoire le goulot d'étranglement, pas la puissance de calcul.

Le "nouveau" GC de hotspot (G1-GC), inclut dans le jdk6/7, est censé abandonner le principe du Mark-Sweep qui induit tous les problèmes dont tu parles.

[pip1000]

C'est interessant mais ca reste mystique quand meme: C'est pas en RAM, c'est pas sur le disque dur, c'est rapide et constant... Ok d'accord, ils sont ou les 100 Gigas de données?

Pour le GC de sun il peut etre multithreadé (pour les collections mineurs) en utilisant -XX:+UseParallelGC, il est d'ailleurs possible de préciser le nombre de thread: -XXarallelGCThreads=

[tchize_]

C'est interessant mais ca reste mystique quand meme: C'est pas en RAM, c'est pas sur le disque dur, c'est rapide et constant... Ok d'accord, ils sont ou les 100 Gigas de données?

C'est en RAM, mais pas dans la zone gérée par le GC. Grosso merdo si je comprends bien c'est avoir une zone parallèle à java où c'est ton programme qui gère les données (entrée et sortie de la zone)

[TheNOHDirector]

@tchize_ Et XX:+UseConcMarkSweepGC (Concurrent Mark and Sweep) c'est quoi

@Florian Goo Sans rentrer dans les détails, en C/C++ tu as vraiment intérêt à savoir ce que tu fais, encore plus que Java, typiquement ou est-ce tu alloues ton espace mémoire, la stack ou dans la heap, c'est important, parceque si les objets sont alloués sur la heap en C/C++ et bien question processeur il risque d'y avoir des caches miss (vous savez sur les caches généralement appelés L1, L2).
Alors qu'en Java, c'est la JVM qui décide, et elle a le temps d'optimiser le code natif (c'est le WarmUp Time).
En plus de ça aujourd'hui le nombre d'instruction machine pour allouer de la mémoire en Java juste sur la Heap est de 4 instructions (10 sur une JVM 1.4), en C/C++ les malloc utilisent en général entre 70 et 100 instructions machines à chaque appel et pourtant ce code a eu le temps de devenir mature pendant ces ~50 dernières années.
Les techniques de GC dans les langages managés commencent à peine à montrer leur nez, ça fait quand même ~20ans. Et il y a plus de chance d'optimiser sur un gros ensemble que sur 1 seul appel. En revanche il y a d'autres problèmes ailleurs.

@pip1000 Il n'y a pas des masses de possibilités pour cacher des objets du GC en Java pur. Je suppose très fortement l'utilisation des ByteBuffers qui permettent d'allouer de la mémoire native, et donc non géré par le GC, celà dit le OOM sont toujours possibles s'il n'y a plus de place. L'avantage est que la mémoire native est directement géré par l'OS d'ou les temps de réponses élevés. Et c'est aussi pour ça qu'on peut monter à des JVM avec des mémoires de l'ordre de la dizaine de GB. Ça se règle avec -XX:MaxDirectMemorySize.

La difficulté de Ehcache serait donc plus de gérer la mémoire, l'éviction etc.
Cela dit c'est peut-être une bonne idée, mais j'ai encore des doutes sur les difficultés techniques qu'on pourrait rencontrer là dessus.