Découverte de la semaine : Un Core 2 Duo est 64 bits !

Bon… j’ai eu l’impression de découvrir l’informatique cette semaine. J’ai compris, ou plutôt appris qu’un processeur Intel Core 2 Duo possède les extensions EM64T afin de fonctionner en mode 64 bits au lieu du mode 32 bits.

Avant, je pensais que les processeurs Intel à part les Itaniums étaient des processeurs 32 bits seulement. Et que AMD avait développé ses propres processeurs 64 bits (les fameux AMD 64 bits). Ensuite, on avait Microsoft qui a mis en place une version 32 bits de Vista et une version 64 bits de Vista pour répondre à Intel et à AMD. Pour finir, l’acheteur avait le choix entre, soit un ordinateur Intel et donc un Windows Vista 32 bits, ou soit un ordinateur AMD avec un Windows Vista 64 bits.

J’avais même la vision qu’un Windows Vista 64 bits était moins ‘bien’ qu’un Vista 32 bits car c’était associé dans mon esprit à un prix d’achat d’ordinateur moins cher (les processeurs AMD étant moins chers que ceux d’Intel). (Et aussi du certainement à l’effet « Oracle » qui dit que si on prend la base de données Oracle on fait toujours le bon choix de base de données malgré son prix excessif).

Rendons à César, ce qui est à César.

Continuer la lecture de Découverte de la semaine : Un Core 2 Duo est 64 bits !

SAP Memory Analyzer : voilà un vrai outil pour analyser des Heap Dump Java !

Vous avez développé une application JEE, et depuis son passage en production au moins une fois par jour il y a une erreur Java « OutOfMemoryError ». La première réaction a été de dire : mauvaise configuration de la taille maximale de la JVM… vous avez préconisé 1Go de Max Heap Size, cela n’a pas fonctionné, l’erreur OOME arrive encore… Alors on est passé à 2Go… Toujours l’erreur d’OOME… Aie, et que faire…

Quand vous êtes à ce point, vous pouvez être certain que vous avez une fuite de mémoire (memory leaks) quelque part. Oh, ce n’est pas que vous êtes un mauvais développeur 😉 et que vous ne savez pas bien gerer la mémoire, en effet, parfois un problème de fuite de mémoire peut survenir à cause d’une fonctionnalité activée du serveur d’applications de production et qui rentre en « conflit » avec une brique de l’application. (Je citerai un exemple vécu : le cache (activé) JDBC de la source de données WebSphere 5.1 et un framework maison de mapping O/R)

Quand on a un problème d’OutOfMemory, on commence souvent par activer le mode verbeux du Garbage Collector (GC), c’est une très bonne idée, cela permet d’avoir une petite idée sur le déroulement du problème de mémoire (on peut utiliser l’outil Extensible Verbose Toolkit d’IBM pour ce travail, cf références). Cependant c’est insuffisant pour trouver la cause du problème. Quelques recherches sur Internet vous apprennent qu’il est possible d’avoir une image de la mémoire Java avec la génération d’un « heap dump », ensuite il suffit de l’analyser pour trouver la cause de la fuite de mémoire. Facile à écrire, mais dur à faire…

Continuer la lecture de SAP Memory Analyzer : voilà un vrai outil pour analyser des Heap Dump Java !