josm et escaliers

Depuis que j’ai mis des escaliers sur la partie que je suis en train de mapper, josm est devenu super lent, a la limite du plantage.
Il faut que j’attende en moyenne 15 secondes entre chaque clicks …

Quand je le redémarre, ça va un peut mieux pendant quelques secondes, puis il se re-bloque …

quelqu’un sait pourquoi?

je suis en train d’éditer à:
48°48"10’ N
2°14"10’ E

Bonsoir,

Plus probablement un probleme mémoire insuffisante, si la zone que tu édite s’étend progressivement la mémoire occupé par josm aussi et assez vite, on arrive assez vite aux limite par défaut de java. Pour déplacer cette limite il faut entrer des option au lancement de java et josm, c’est expliqué dans le wiki, recherche java et commande xmx=1024 …

Cordialement

Je suivais l’évolution de josm avec top, et je regardais tout, y compris la mémoire, mais je n’ai pas vu de problème de ce coté la … après, c’est peut être le garbage collector qui fait des blagues …
Mais vu que quand ça se mettais a se ralentir, c’était tout mon système qui était a genoux (même mes autres appli) … je pensait que josm bourrinais méchamment tous mes cœurs de pross …
Mais c’est vrai que j’ai rajouté pas mal d’objets …
Je vais essayer de booster la mémoire autorisé pour ma jvm, à coup de xmx … voir du coup, je vais reprendre la flopée d’option que j’utilise pour mon eclipse et qui m’absolvent de tout problème de limite de mémoire de la jvm.
-XX:MaxPermSize=4096m
-Xms512m
-Xss512m
-Xmx4096m

merci
(mais bon, vu que je suis en 32 bits, et qu’il semble que bizarrement, la limite d’adressage par programme semble être la plage d’un signed int, mes appli n’arrivent jamais a adresser plus de 2Go de ram (et après ça seg fault). Donc si c’est la qu’est le problème … au mieux, j’aurais un plantage franc a la place de ce ralentissement).

La, j’ai pris un rectangle plus petit a éditer … et ça va mieux, pour l’instant ça marche …
mais pour tester, j’ai pris une très grande zone (sans options de jvm) … et la, ça marche aussi …
bon c’est bizarre … mais en fait, la, j’ai rien fait, et on dirrait que ça remarche …

sinon, voila l’état avant le dernier blocage: (la jvm prenait déjà 1,5 Go).
PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
20 0 1225m 257m 24m S 96 3.2 0:03.81 java

puis je vais faire un peut de ménage aussi en mémoire, car j’ai d’autres appli qui me bouffe toute ma ram …
20 0 1287m 752m 34m S 9 9.3 460:07.97 firefox
et peut être relancer mon interface graphique que j’ai un peut maltraité …
20 0 787m 257m 14m S 9 3.2 1592:39 Xorg


===============================================================================================================

Edit:
Ok, je viens de comprendre.
josm n’aime pas avoir des effets/fenêtres opengl qui chevauchent la sienne.

Il me semble que 1.5Go c’est le maximum disponible pour les application java en 32 bit … donc tu devait être au taquet.

Effectivement. Si tu veux utiliser JOSM en version 64 bits, ajoute le paramètre “-J-d64” dans la ligne de commande du raccourci de lancement du fichier JNLP ou du jar (évidemment il faut avoir installé en plus la version 64 bits de Java, qui ne se met pas à jour toute seule comme la version 32 bits, et qu’on installe par un téléchargement classique).
Ensuite tu peux ajouter le paramètre “-Xmx=4G” pour passer ta VM Java à 4Go.

Attention en mode 64 bits, Java utilise un peu plus de mémoire (il pallie en partie le problème pour les VM de moins de 32 Go en utilisant en interne ce qu’il appelle des “oop”, c’est à dire en stockant les pointeurs d’objets sur 32 bits, après les avoir tous alignés sur des adresses multiples de 8 : un oop de 32 bits peut donc accéder à 8*2^32 octets dans une même VM, soit… 32 Go tout de même :wink:.

Les “oops” sont disponibles par défaut depuis Java 7 (dans Java 6 il faut ajouter un paramètre optionnel pour les activer, mais on reste limité par une taille de VM de moins de 3Go en 32 bits, au lieu de 1.5Go sans les oops).
Moralité: passez de Java 6 à Java 7, même en version 32 bits, car cela double la taille de VM maximale disponible (sinon activez le support des oops pour Java 6 avec l’option de VM ad hoc, car ce support n’a pas été finalisé dans cette version où ils étaient là de façon expérimentale et seulement à la demande).

Les oops peuvent aussi être utilisés en version 64 bits pour les VMs de moins de 32 Go car cela divise par deux la taille des pointeurs (au prix d’une microscopique instruction CPU pour faire les multiplications par 8 pour transformer les pointeurs d’objets internes à la VM, en pointeurs virtuels 64 bits utilisables par le CPU : ce qu’on perd avec une instruction est de toute façon largement gagné par la réduction de la mémoire accédée en cache du processeur, et donc cela va aussi plus vite).

Java 7 a aussi un autre intérêt : on évite les pauses du Garbage Collector. Les 15 secondes que tu vois sont du au fait que le Garbage Collector de Java 6 et d’avant doit sans arrêt se lancer en mode bloquant quand tu atteints les limites de taille max de ta VM. Java 7 utilise pour cela un nouveau Garbage Collector qui divise sa tâche à faire en plusieurs sous-tâches de façon à garantir un temps de réponse : ils fait des passes successives partielles, en arrière-plan et limite son travail à moins d’une seconde. Le nouveau Garbage Collector améliore considérablement les choses en terme de réactivité car ses phases bloquantes sont beaucoup moins longues, même s’il ne fait plus la collecte sur la totalité de la VM en une seule passe.

Personnellement je ne me pose plus la question et j’utilise la version 64 bits de Java, en lançant JOSM avec le fichier JNLP une fois, puis en sortant et modifiant le raccourci créé sur le bureau pour lui ajouter le paramètre “-J-d64” afin de relancer le JNLP en 64 bits. Vérifie que tu utilises bien la version 64 bits en activant la console Java, ain de voir les messages de log de Java qui détaille les paramètres de lancement utilisés et les paramètres de création de la VM. Une fois que la console a affiché ce qu’il faut, tu peux la fermer si elle te gène, ou la réduire sur la barre des tâches.