Reprise du message précédent :
ouasi mais en fait c est pas tellement niveau perf que je recherche.  
il se trouve qu il y a une partie JNI + une interface avec une DLL faite avec des JNI.
 
et parfois, l applicaiton juste freeze. snas lancer aucune exception. -> JVM qui crash???
pour l instant c est vraiment plus important d avoir qq chose de stable.
 
apres, pkoi pas ne pas tester la JVM de BEA. j aimerais bien mais j ai pas forcement tout le temps que je souhaiterais

est ce que qqun a un compte chez BEA que je puisse dl leur JVM?
 
Visibilement les N/A et 1234 du formulaire ne leur ont pas plus, ils veulent pas me filer un accès

si la jvm se crashe tu as tjrs un fichier pid avec le dump de la pile dans le rep ou tu as lancé l'appli

justement je dois faire ce genre de bench pour mon taf dans un avenir plus ou moins proche. J'ai fait un petit test très débile mais bon juste pour avoir une idée:
 
Démarrage du même JBoss dans des conditions similaires (c'est un test à la louche hein mais bon):
 
- SUN 1.4.2_03 : 44 sec et 32ms
- IBM 1.4.1: 32 sec et 648ms
 
ca fait plus ou moins 25% qd meme, meme si ct à la louche

Dark, je t'ai envoyé un mp avec mon accès BEA...
 
K.

un grand merci à l'inconnu (pas si inconnu que ça) qui m'a filé son compte chez BEA
 

bin je me suis dénoncé  

t'as pas honte?
 
Et donc tu confirmes qu'on peut l'utiliser gratuitement cette jvm?
 
 Error during execution, error code = 11.
 
ca commence bien

avec le même -XX:CompileThreshold ?

ptain je suis trop fort
 
LD_ASSUME_KERNEL=2.4.1 strace -f -o /tmp/strace
 
et ca marche

 

dis m'en plus
j'ai pas touché à cette option

j'ai un segmentation fault avec la JVM de bea

 
tout compte fait

de manière générale, évite de faire un bench au démarrage, tous les chaches sont froids, et tu favorises le compilateur le plus rapide.
 
Sachant que produire du code rapide demande du temps (because coloration de graphe pour l'allocation des registres et code scheduling) et que tu ne laisse pas le plus lent des compilo exprimer son éventuel meilleur code qui compenserait le temps passé à le produire, c'est très mauvais comme bench. Si tu as une application qui a un temps de vie très petit alors il faut désactiver les compilos.
 
l'argument que je t'ai montré, c'est le nombre de fois que la JVM passe dans la brache avant de la compiler, par défaut sous mac c'est 1000, le 1001ème passage se fera dans une version compilée de la branche.

j'ai dit que ct un test en vitesse à la louche
cela dit si tu as des liens pour faire des benchs plus précis (pq un outil meme commercial) fais signe

non, mais ton test il est pas bon, même à la louche.
 
fait tourner une application, mais ne mesure pas le temps de démarrage, c'est tout, ça reste à la louche.

 
bon ct pas un test. Content?
J'aurai pas du utiliser le mot 'test'. C'était pas de ce sens là que je le voyais

Salut,
 
C'est juste pour rapporter une p'tite expérience que j'ai eue.
Les JVM Sun et IBM respectent les mêmes spec, mais ne sont pas forcément implémentées de la même manière.
 
Notamment pour ce qui concerne la reflexion. J'avais un prog qui recherchait les attributs d'une classe (par réflexion, pour rendre le prog un peu générique) compilé avec javac de SUN. Lorsqu'on l'exécutait avec la JVM de SUN l'ordre des attributs trouvés était celui de la déclaration dans la classe tandis qu'avec la JVM d'IBM l'ordre était inversé...
 
Comme quoi on peut avoir des comportement différents selon les JVM.
 
A+.