Publicité
+ Répondre à la discussion Actualité déjà publiée
Affichage des résultats 1 à 18 sur 18
  1. #1
    Expert Confirmé Sénior
    Avatar de Idelways
    Homme Profil pro Ihssen Idelways
    Développeur Ruby on Rails / iOS
    Inscrit en
    juin 2010
    Messages
    1 378
    Détails du profil
    Informations personnelles :
    Nom : Homme Ihssen Idelways

    Informations professionnelles :
    Activité : Développeur Ruby on Rails / iOS

    Informations forums :
    Inscription : juin 2010
    Messages : 1 378
    Points : 65 067
    Points
    65 067

    Par défaut BigMemory résout-il le « problème universel » de Java ? Terracotta sort une solution aux limitations du GC

    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 ?

  2. #2
    Membre chevronné
    Avatar de Florian Goo
    Profil pro
    Inscrit en
    septembre 2008
    Messages
    680
    Détails du profil
    Informations personnelles :
    Âge : 28
    Localisation : France, Paris (Île de France)

    Informations forums :
    Inscription : septembre 2008
    Messages : 680
    Points : 720
    Points
    720

    Par défaut

    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…
    Cours : Initiation à CMake
    Projet : Scalpel, bibliothèque d'analyse de code source C++ (développement en cours)
    Ce message a été tapé avec un clavier en disposition bépo.

  3. #3
    Membre du Club
    Inscrit en
    janvier 2006
    Messages
    50
    Détails du profil
    Informations forums :
    Inscription : janvier 2006
    Messages : 50
    Points : 55
    Points
    55

    Par défaut

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

  4. #4
    Invité régulier
    Profil pro guillaume
    Inscrit en
    septembre 2010
    Messages
    4
    Détails du profil
    Informations personnelles :
    Nom : guillaume
    Âge : 27

    Informations forums :
    Inscription : septembre 2010
    Messages : 4
    Points : 6
    Points
    6

    Par défaut

    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 !

  5. #5
    Expert Confirmé Sénior Avatar de Uther
    Homme Profil pro
    Inscrit en
    avril 2002
    Messages
    3 027
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations forums :
    Inscription : avril 2002
    Messages : 3 027
    Points : 5 829
    Points
    5 829

    Par défaut

    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.

  6. #6
    Membre chevronné Avatar de Julien Bodin
    Homme Profil pro Julien Bodin
    Ingénieur développement logiciels
    Inscrit en
    février 2009
    Messages
    463
    Détails du profil
    Informations personnelles :
    Nom : Homme Julien Bodin
    Âge : 27
    Localisation : France, Calvados (Basse Normandie)

    Informations professionnelles :
    Activité : Ingénieur développement logiciels
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : février 2009
    Messages : 463
    Points : 720
    Points
    720

    Par défaut

    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.

  7. #7
    Membre expérimenté
    Inscrit en
    mars 2010
    Messages
    537
    Détails du profil
    Informations forums :
    Inscription : mars 2010
    Messages : 537
    Points : 539
    Points
    539

    Par défaut

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

  8. #8
    Membre chevronné
    Avatar de Florian Goo
    Profil pro
    Inscrit en
    septembre 2008
    Messages
    680
    Détails du profil
    Informations personnelles :
    Âge : 28
    Localisation : France, Paris (Île de France)

    Informations forums :
    Inscription : septembre 2008
    Messages : 680
    Points : 720
    Points
    720

    Par défaut

    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.
    Cours : Initiation à CMake
    Projet : Scalpel, bibliothèque d'analyse de code source C++ (développement en cours)
    Ce message a été tapé avec un clavier en disposition bépo.

  9. #9
    Membre expérimenté
    Inscrit en
    février 2010
    Messages
    230
    Détails du profil
    Informations forums :
    Inscription : février 2010
    Messages : 230
    Points : 511
    Points
    511

    Par défaut

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

  10. #10
    Modérateur
    Avatar de bouye
    Homme Profil pro Fabrice Bouyé
    Développeur Java
    Inscrit en
    août 2005
    Messages
    4 421
    Détails du profil
    Informations personnelles :
    Nom : Homme Fabrice Bouyé
    Âge : 37
    Localisation : Nouvelle-Calédonie

    Informations professionnelles :
    Activité : Développeur Java
    Secteur : Agroalimentaire - Agriculture

    Informations forums :
    Inscription : août 2005
    Messages : 4 421
    Points : 9 075
    Points
    9 075

    Par défaut

    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.
    Merci de penser au tag quand une réponse a été apportée à votre question. Aucune réponse ne sera donnée à des messages privés portant sur des questions d'ordre technique. Les forums sont là pour que vous y postiez publiquement vos problèmes.

    suivez mon blog sur Développez.

    Programming today is a race between software engineers striving to build bigger and better idiot-proof programs, and the universe trying to produce bigger and better idiots. So far, the universe is winning. ~ Rich Cook

  11. #11
    Expert Confirmé Sénior Avatar de Uther
    Homme Profil pro
    Inscrit en
    avril 2002
    Messages
    3 027
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations forums :
    Inscription : avril 2002
    Messages : 3 027
    Points : 5 829
    Points
    5 829

    Par défaut

    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.

  12. #12
    Expert Confirmé Sénior
    Avatar de tchize_
    Homme Profil pro
    Responsable de service informatique
    Inscrit en
    avril 2007
    Messages
    21 190
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 35
    Localisation : Belgique

    Informations professionnelles :
    Activité : Responsable de service informatique
    Secteur : Service public

    Informations forums :
    Inscription : avril 2007
    Messages : 21 190
    Points : 34 860
    Points
    34 860

    Par défaut

    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.
    Tchize (Чиз) faq java, cours java, javadoc. Pensez à et
    Laisse entrer le jour après une nuit sombre. Si tu es toujours là, tu n'es pas faite pour mourir.

  13. #13
    Membre éclairé
    Inscrit en
    juin 2006
    Messages
    349
    Détails du profil
    Informations forums :
    Inscription : juin 2006
    Messages : 349
    Points : 358
    Points
    358

    Par défaut

    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 ?

  14. #14
    Expert Confirmé Sénior
    Avatar de tchize_
    Homme Profil pro
    Responsable de service informatique
    Inscrit en
    avril 2007
    Messages
    21 190
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 35
    Localisation : Belgique

    Informations professionnelles :
    Activité : Responsable de service informatique
    Secteur : Service public

    Informations forums :
    Inscription : avril 2007
    Messages : 21 190
    Points : 34 860
    Points
    34 860

    Par défaut

    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.
    Tchize (Чиз) faq java, cours java, javadoc. Pensez à et
    Laisse entrer le jour après une nuit sombre. Si tu es toujours là, tu n'es pas faite pour mourir.

  15. #15
    Rédacteur/Modérateur
    Avatar de pseudocode
    Homme Profil pro Xavier Philippeau
    Architecte système
    Inscrit en
    décembre 2006
    Messages
    9 961
    Détails du profil
    Informations personnelles :
    Nom : Homme Xavier Philippeau
    Âge : 41
    Localisation : France, Hérault (Languedoc Roussillon)

    Informations professionnelles :
    Activité : Architecte système
    Secteur : Industrie

    Informations forums :
    Inscription : décembre 2006
    Messages : 9 961
    Points : 15 082
    Points
    15 082

    Par défaut

    Citation Envoyé par tchize_ Voir le message
    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.
    ALGORITHME (n.m.): Méthode complexe de résolution d'un problème simple.

  16. #16
    Membre du Club

    Inscrit en
    octobre 2006
    Messages
    27
    Détails du profil
    Informations forums :
    Inscription : octobre 2006
    Messages : 27
    Points : 61
    Points
    61

    Par défaut

    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=

  17. #17
    Expert Confirmé Sénior
    Avatar de tchize_
    Homme Profil pro
    Responsable de service informatique
    Inscrit en
    avril 2007
    Messages
    21 190
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 35
    Localisation : Belgique

    Informations professionnelles :
    Activité : Responsable de service informatique
    Secteur : Service public

    Informations forums :
    Inscription : avril 2007
    Messages : 21 190
    Points : 34 860
    Points
    34 860

    Par défaut

    Citation Envoyé par pip1000 Voir le message
    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)
    Tchize (Чиз) faq java, cours java, javadoc. Pensez à et
    Laisse entrer le jour après une nuit sombre. Si tu es toujours là, tu n'es pas faite pour mourir.

  18. #18
    Membre du Club
    Profil pro
    Inscrit en
    avril 2006
    Messages
    51
    Détails du profil
    Informations personnelles :
    Localisation : France, Paris (Île de France)

    Informations forums :
    Inscription : avril 2006
    Messages : 51
    Points : 59
    Points
    59

    Par défaut

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

Liens sociaux

Règles de messages

  • Vous ne pouvez pas créer de nouvelles discussions
  • Vous ne pouvez pas envoyer des réponses
  • Vous ne pouvez pas envoyer des pièces jointes
  • Vous ne pouvez pas modifier vos messages
  •