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 ?

[lequebecois79]

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

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

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