Note pour plus tard: Problème avec jVisualVM sur OSX

Au cour d’un petit development, j’ai remarqué que mon process ne se terminait pas, une fois l’exécution de mon code terminé. Il devait y avoir soit une thread qui tournait encore, soit un deadlock quelque part, j’optais plus pour la seconde option.

Du coup je lance jvisualvm depuis mon terminal (celui du JDK7 update 7). Là j’ai la liste des process java qui tournent malheureusement quand je choisi d’investiguer ce process, jvisualvm me rapporte sur le terminal :

L’onglet du process s’ouvre bien dans jvisualvm mais impossible monitorer les threads ni faire de heap dump (au cas ou ça m’intéresserai), d’ailleurs ces sous-onglets ne sont même pas affiché.

La solution: passer avant au process java qu’il faut monitorer les paramètres suivants (en fonction des besoins)

  • -Xverify:none : Désactive la vérification du bytecode dans la JVM. De base la JVM s’assure que le bytecode vérifie certaines règles. Bref il faut activer ce flag si vous voulez faire des thread dump ou des heap dump. Il s’agit probablement d’un bug du JDK7 ou de jVisualVM sur OSX.
  • -Xshare:off : Comme son nom l’indique il s’agit de partager de la mémoire, dans les faits ça se traduit par le partage des classes déjà chargé. Sur mac cette option est active par défaut. A priori cette option pose problème pour l’attachement à un process Java, du coup en isolant la mémoire du process on peut s’en sortir.
  • -Dcom.sun.management.jmxremote : Active l’export des MBean de la JVM, si vous voulez les monitorer

On dirait une réapparition dans le JDK7u7 d’un bug a priori déjà clos dans le JDK6 (pour OSX). A noter que les outils en ligne de commade tel que jmap peuvent aussi être affectés.

Bien entendu si j’ai loupé un truc je suis tout ouïe.

Référence : http://java.net/jira/browse/VISUALVM-326

Caliper me : Ou pourquoi les microbenchmarks aident !

Contexte

Dans les news récemment

  • Guava 13.0 réduit la consommation en mémoire de plusieurs structures [source]
  • J’ai passé des tests d’algorithmie [source]

Premier point, on sait que Google est attentif sur les performances de ses librairies. Sur le deuxième point, ben j’ai finalement loupé un des exercices “timeboxés”, je n’ai pas eu le temps de le finir a temps, du coup le code soumis était 100 % foireux. Mais bon ce n’est pas le sujet du billet, ce qui est important c’est que j’ai fini après cet algo, puis je me suis rendu compte que celui-ci n’était pas optimal, il ressemblait à un algo en O(n2) O(n log n) (Merci Sam pour cette correction). Du coup j’ai repris le papier et le crayon, et je me suis rendu compte que je pouvais utiliser une technique similaire à celle que j’ai utilisé sur le premier algo du test (comment n’ai-je pas pu y penser à ce moment d’ailleurs ?).

De mémoire l’algo porte grosso modo sur le comptage de paires d’entier distante d’un nombre K dans un tableau A.

Ma première version :

Alors pourquoi je pense que cet algo n’est pas optimal : simplement du fait des boucles inbriquée, on dirait du O(n2) O(n log n) (voir ici pourquoi). Mais quand on parle de la performance ou de la complexité d’un algorithme il ne faut prendre uniquement compte de l’invariant mais aussi du jeu de données : quelle taille ? quelle distribution ? quel type de données ?

En effet un algorithme pour être efficace doit être adapté aux jeux de données qu’il aura à traiter et à l’usage qu’on en a ; peut-être à travers des paramètres ou des structures différentes, typiquement un des constructeur d’une HashMap prend des paramètres comme le facteur de charge et la taille initiale, on pourra choisir une TreeMap au lieu d’une HashMap si la recherche est un cas d’utilisation de la structure de donnée.

Bref du coup voilà à quoi ressemble la nouvelle version de cet algo :

Donc ici l’idée c’est de préparer dans un premier temps un dictionnaire  inversé basé sur un des entier et la distance demandée, en incrémentant pour chaque occurence. Ici une seule boucle for, car on parcours en entier le tableau. Dans un second temps on cherche les entiers qui correspondent effectivement à l’entrée de ce dictionnaire, et si oui on incrémente le compteur de paires. Là aussi une seule boucle sur le tableau donc O(n). Sachant qu’une HashMap a souvant une complexité de O(1) pour l’insertion et la recherche, a vue de nez l’algo est plutot pas mal.

Bon mais dans la réalité ca donne quoi, en effet comme Kirk Pepperdine et bien d’autres disaient : Measure ! Don’t guess !

Caliper me voilà !

Caliper est un outil codé par des personnes de chez Google, il est notamment utilisé par l’équipe en charge de Guava. On peut d’ailleurs voir dans les sources de Guava les benchmarks ici par exemple.

Avec un projet “mavenisé” on récupère la dernière version de caliper, la version 0.5-rc1 aujourd’hui.

Pour écrire un benchmark caliper il suffit d’étendre la classe SimpleBenchmark, puis d’écrire des méthodes public int avec le préfixe times et un paramètre répétition utilisé dans une boucle for. Pour passer des paramètres particuliers au benchmark on utilisera un ou des champs annoté(s) par @Param.

Enfin comme Caliper lance une nouvelle VM, fait quelques travaux pour chauffer la VM (warmup), etc, il faut pour l’instant lancer ces tests avec une commande manuelle :

La ligne de commande pourra varier suivant les besoins ; on peut notamment se rendre sur leur site pour y voir les options (le lien wiki est à ce jour en retard par rapport au code) à passer au Runner Caliper. Malgré la jeunesse du framework sa documentation parfois spartiate, le projet a de réelles forces et s’avère de plus en plus populaire dans le domaine. Bien que le développement de ce projet avance lentement, ce projet est aujourd’hui maintenu par des membres de l’équipe Guava.

Donc le benchmark que j’ai mis en place :

Dans le temps

Voilà il faut maintenant lancer le benchmark en ligne de commande. Et voici une partie de la sortie standard :

Donc en fait Caliper créé une matrice multi-dimensionnelle des différents paramètres et pour chaque coordonnée dans cette matrice lance le test, bref un Scénario.

On voit dans les mesures faites par Caliper le temps pris par chaque méthode, l’écart type, et le nombre d’essai. Enfin dans une deuxième partie Caliper donne un synopsis des différents run et en particulier une colonne très intéressante ‘linear time‘.

En observant le temps pris en fonction du nombre d’éléments pour chaque algo, on s’aperçoit que le temps pris par le premier algo augmente en effet par rapport au deuxième algo d’un facteur 5 qui augmente avec la taille du tableau. Bref on est loin d’un temps linéaire aka O(n).

Ce qui est aussi intéressant, c’est que le premier algo est plus efficace tant que le nombre d’élément dans le tableau d’entrée est inférieur à 100. Alors que la deuxième  qui utilise une structure plus élaboré ne montre des signes avantageux qu’à partir d’une centaine d’éléments. Ca me rappelle étrangement l’électronique ou les comportements des capacités et inductances changeant de nature lorsqu’on passe en haute fréquence.

Dans l’espace

Alors pour faire les mesures des allocations, on peut aussi utiliser caliper, mais à l’heure de l’écriture de ce blog, il faut faire quelques petites choses en plus.

  1. Caliper 0.5 RC1 vient avec le jar java-allocation-instrumenter-2.0.jar qui est sensé servir d’agent, cependant ce jar n’a pas été généré correctement pour servir d’agent. En fait il faut télécharger le jar allocation.jar de ce projet : http://code.google.com/p/java-allocation-instrumenter/ daté du 1 er février 2012.
  2. Avant de lancer le Runner en ligne de commande il faut ajouter la variable d’environnement ALLOCATION_JAR
  3. Enfin il est possible de lancer le même benchmark avec des tests sur la mémoire :

 

A noter : Ne pas renommer allocation.jar en autre chose, sans ça vous n’aurez pas d’instrumentation !

Ce qui donne le résultat suivant, quasiment la même chose, mais avec les infos sur les allocations mémoire.

C’est effectivement une information utile, la première version de l’algo, ne fait en fait qu’une seule allocation de 16B (donc en fait un seul objet), c’est à dire peanuts, on est dans du O(1) en complexité spatiale. La deuxième qui est notamment basée sur une HashMap alloue nettement plus d’objets, mais est définitivement plus rapide, on a on ici une complexité spatiale de O(n).

Comme quoi il y a potentiellement des compromis à faire dans le choix d’un algo, la rapidité ou la faible consommation mémoire peuvent venir avec un coût dans une autre dimension.

Pour conclure

  • Premier point, il faut absolument être au point pour des tests d’embauche plus sur le sujet, même si je trouve limité ces tests dans leur capacité à identifier ou filtrer les bons développeurs (l’algorithmie n’est pas certainement pas le seul critère d’un individu doué), c’est toujours bien de pouvoir les reéussir !
  • Caliper offre un outillage plutôt facile d’utilisation pour faire des microbenchmark, dans la limite de validité d’un microbenchmark, il y a plein de mise en garde sur le sujet, sur le site de Caliper [1][2], Cliff Click en a parlé aussi à JavaOne [3][4].
  • Quand on écrit du code c’est une bonne idée de penser à la complexité temporelle et spatiale, dont la notation pour les deux est le grand O. Caliper pourrait d’ailleurs se voir ajouter le moyen de mesurer la consommation mémoire (en lien avec la complexité spatiale). Évidement ce que je dis ne veut pas dire optimiser prématurément, mais juste de réfléchir à quel type de performance on peut s’attendre pour telle ou telle partie du code, et éventuellement de porter plus tard un effort spécifique.

A noter que Caliper offre d’autres possibilités de mesurer la performance à travers une méthode annotée par @ArbitraryMeasurement.

Script d’installation du JDK 5 sur MacOSX Lion et Mountain Lion (Mis à jour)

MAJ 29/07/2012: Le script a été mis à jour pour fonctionner avec Mac OS X Mountain Lion. Le script a été mis à jour pour télécharger lui même le DMG chez Apple, en bref il n’y a plus qu’à commencer à l’étape 2.

JDK 5 installation on Mountain Lion


Original 22/08/2011 : Avec l’arrivée de Lion, Apple change les choses avec Java. Heureusement s’il s’agit d’une mise à jour depuis Snow Leopard, vous ne perdrez pas votre runtime JDK 6, en revanche si vous faites une installation clean, et bien il faudra télécharger le runtime ici :

http://support.apple.com/kb/DL1421

Bon ça fait une chose de plus pour nous ennuyer, mais bon comme toujours pour ceux qui veulent bosser sur un JDK 1.5, il vous faudra tricher un peu plus, il n’y a pas de mise à jour standard ou facile pour installer le JDK 5 sur 10.7.

Certains ont trouvé l’astuce en téléchargeant la mise à jour Java pour Mac OS X 10.5, et avec quelques outils et commandes dans le terminal. Cela dit le processus est un poil long. Du coup je me suis codé un petit script pour automatiser ces étapes. Pour l’instant le script repose sur un téléchargement manuel de cette mise à jour.

  1. En premier on télécharge la mise à jour du JDK5 ici :

    http://support.apple.com/kb/DL1359

  2. Ensuite dans le même répertoire on y téléchargera le script
  3. Dans un terminal dans le dossier du téléchargement
    [plain]chmod +x install_jdk5_lion.sh[/plain]
  4. Il faut être root, attention quand même, le script fonctionne sur les environnements Lion que j’ai pu testé, mais il peut très bien casser votre système, déclencher un tempête ou je ne sais quoi encore… je ne garantis rien.
    [plain]sudo -s[/plain]
  5. Bref il se lance comme ça :
    [plain]./install_jdk5_lion.sh[/plain]
  6. Si tout se passe bien alors, les préférences Java de Mac s’ouvriront en listant le JDK 5.
  7. exit

En images, ça donne :

Evidement si vous repérez une coquille, je suis à l’écoute. Bonne soirée :)

EDIT 29/08/2011: Tant qu’à faire autant montrer comment avoir plusieurs JDK dans IntelliJ sous macosx.

  1. Donc une fois le projet ouvert, il faut aller dans les préférences du projet (Project Settings).
    IntelliJ Project Setting
  2. Ensuite ajouter le JSDK.
    Add New JSDK
  3. Puis sélectionner dans l’explorateur le dossier /System/Library/Java/JavaVirtualMachines/1.5.0/Contents/Home
    Choose JDK 5 Home
  4. Hop, c’est fini, dans IntelliJ vous avez le JDK 5

Idée originale : Zend Studio 5.x for OS X Lion (Java SE 6)

Sources :

Hackergarten Paris – ce qu’il faut savoir sur les projets

Hello à tous,

Hackergarten Logo

Mercredi 7 mars (à 19h) aura lieu la 2ème session Hackergarten. Après Soat, on a le plaisir d’être hébergé par Valtech (103 Rue de Grenelle, 75007 Paris) et il y aura des pizzas, gros merci à eux.

Hackergarten c’est le rendez-vous des gens qui veulent participer aux projets opensource. L’idée c’est, dans un format de 3h, de contribuer un logiciel, un fix, un feature, une documentation dont d’autres pourraient avoir l’usage. Il s’articule autour de commiters actifs pour mentorer les hackers qui participent à l’évènement.

Bref que du bon. Pour la planification de l’évènement c’est par là ⇒ http://hackergarten-paris.eventbrite.com/

Alors pour éviter les soucis de setup le jour J, ce post donne quelques informations sur ce qu’il y aurait à récupérer ou faire en avance sur votre machine. Si vous avez des questions ou si vous voulez participez aux discussions : inscrivez vous sur la mailing-list à cette adresse ⇒ http://groups.google.com/group/hackergarten-paris/

Continue reading “Hackergarten Paris – ce qu’il faut savoir sur les projets” »

Mockito 1.9.0 is out – Bientôt sur les repos maven

EDIT: Hop. Enfin la release 1.9.0 est dispo en téléchargement.

Après pas mal de travail avec des périodes plus ou moins intenses – bref les vicissitudes du développement Open Source – le projet sort une nouvelle version 1.9.0 en Release Candidate, avec des bugfixes et bien sûr des nouvelles features. Il y a un changelog mais dans les faits le billet suivant liste brièvement ce qui est nouveau. Ah oui la version est téléchargeable ici et bientôt disponible sur le central maven.

  • Pour être plus fluent et expressif, l’API introduit les alias then et will pour les réponses personnalisées (Answer). Ainsi que d’autres petits tweak de l’API:
  • Les mocks peuvent maintenant être déclaré dans la configuration du stub, sur une ligne.
  • On peut maintenant renvoyer la classe d’une exception plutôt que son instance.
  • Si jamais vous avez besoin de debugguer un bout de code ou les interactions sont non prédictibles, il est maintenant possible de loguer les invocations du mock ou de l’espion. Attention, bien qu’utile à l’occasion avec du code legacy, quand même si jamais ce besoin s’en fait sentir sur un nouveau développement c’est que ce code devient trop complexe.

    On pourra également ajouter des callbacks sur chaque interaction du mock.
  • Pas mal de travail a été fait sur les annotations. Maintenant il n’est plus nécéssaire d’initialiser un champ annoté par @Spy s’il existe dans la classe un constructeur sans argument.
  • Et pour la fin mais pas des moindres, le mécanisme d’injection de mockito supporte maintenant l’injection par constructeur. A l’heure actuelle, seul les mocks et spies déclaré dans le test en tant que champs pourront être injecté dans le constructeur du champs annoté par @InjectMocks.

    Ou Engine a un constructeur avec le paramètre Diesel.

Pour l’instant en RC, cette release permettra d’adoucir les angles si nous en avons loupé certains éléments. N’hésitez pas à nous poser des questions sur la mailing list ou stackoverflow.

Performance Optimization WordPress Plugins by W3 EDGE