Le 10 février 2012 22:46, Claude <claude.mar...@gmail.com> a écrit : > j'ai lancé en ligne de commande juste avec java -jar josm-tested.jar plus de > plantage mais il est vrai qu'il a aparement écrasé mon fichier de config car > mes paramètre OAuth ont suaté
Cela est un signe clair que lors des bloquages, OSM a manqué de mémoire pour réaliser une opération, et ce manque de mémoire a provoqué une corruption des données qu'il a voulu enregistrer dans tes paramètres. J'ai déjà remarqué que même avec de petits fichiers OSM, 1Go de RAM allouée pour la machine Java c'est un peu juste pour JOSM: le garbage collector de Java n'arrive plus à gérer les "générations" d'objets alloués efficacement, du coup la fragmentation augmente très sensiblement dans l'ancienne génération, et il finit par manquer de place pour la nouvelle génération. Le garbage collector de Java passe alors son temps à recompacter l'ancienne génération, ce compactage étant beaucoup plus couteux en ressource CPU et en temps, et opérations de copies en mémoire, que le compactage de la nouvelle génération (qui n'est qu'une file cyclique). C'est encore plus vrai sur un système avec un seul processeur car le compacteur de l'ancienne génération monopolise le seul thread actif et bloque tout autre thread dans le processus Java (tout en devant aussi céder tu temps au reste de l'OS et aux autres applis du bureaux et services en cours). Le poblème ici avec JOSM c'est la taille assez importante de "l'ancienne génération", qui contient en particulier le code Java compilé en cours d'exécution (JOSM est une appli volumineuse en code, avec tous ses plugins), et ses caches de données et aussi les données de rendu du calque précalculé à l'écran. La nouvelle génération en revanche contient tous les objets alloués en permanence pour la génération des objets XML ou leur décodage et leur affichage, ou leur activation coloré à l'écran et dans les fenêtres de propriétés, ou calculés temporairement en très grand nombre par les fonctions de recherche et de validation. Un fichier OSM chargé sera alloué dans des objets au début dans la nouvelle génération, mais rapidement transférés vers l'ancienne génération (d'autant plus vite que la taille de machine virtuelle -Xmx est petite) JOSM pour moi n'est plus recommandé avec moins de -Xmx1500 car ses gestionnaires d'exception en cas de débordement mémoire ne ratrapent pas toujours bien la situation notamment dans les données qu'il sauvegarde sur fichier ou envoie au serveur. _______________________________________________ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
