IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)

Vous êtes nouveau sur Developpez.com ? Créez votre compte ou connectez-vous afin de pouvoir participer !

Vous devez avoir un compte Developpez.com et être connecté pour pouvoir participer aux discussions.

Vous n'avez pas encore de compte Developpez.com ? Créez-en un en quelques instants, c'est entièrement gratuit !

Si vous disposez déjà d'un compte et qu'il est bien activé, connectez-vous à l'aide du formulaire ci-dessous.

Identifiez-vous
Identifiant
Mot de passe
Mot de passe oublié ?
Créer un compte

L'inscription est gratuite et ne vous prendra que quelques instants !

Je m'inscris !

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

Le , par Idelways

27PARTAGES

1  0 
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 ?

Une erreur dans cette actualité ? Signalez-nous-la !

Avatar de Uther
Expert éminent sénior https://www.developpez.com
Le 17/09/2010 à 14:18
Citation Envoyé par Florian Goo Voir le message
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.
1  0 
Avatar de TheNOHDirector
Membre du Club https://www.developpez.com
Le 23/09/2010 à 17:06
@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.
1  0 
Avatar de phryos
Membre régulier https://www.developpez.com
Le 17/09/2010 à 13:53
Citation Envoyé par Florian Goo Voir le message
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é.
0  0 
Avatar de gmatta
Futur Membre du Club https://www.developpez.com
Le 17/09/2010 à 14:12
Citation Envoyé par phryos Voir le message
+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 !
0  0 
Avatar de Julien Bodin
Membre éclairé https://www.developpez.com
Le 17/09/2010 à 14:23
Citation Envoyé par phryos Voir le message
+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.
0  0 
Avatar de lequebecois79
Membre éclairé https://www.developpez.com
Le 17/09/2010 à 14:30
azul propose des solutions pour ça depuis belle lurettes...
http://www.azulsystems.com/
0  0 
Avatar de Florian Goo
Membre éclairé https://www.developpez.com
Le 17/09/2010 à 14:57
Citation Envoyé par Uther Voir le message
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.
0  0 
Avatar de GCSX_
Membre confirmé https://www.developpez.com
Le 17/09/2010 à 23:29
Et plutôt que de dépenser des fortunes en cherchant à le contourner, pourquoi ne pas optimiser le GC?
0  0 
Avatar de bouye
Rédacteur/Modérateur https://www.developpez.com
Le 17/09/2010 à 23:49
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.
0  0 
Avatar de Uther
Expert éminent sénior https://www.developpez.com
Le 18/09/2010 à 13:41
Citation Envoyé par Florian Goo Voir le message
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.
0  0