Le Mercredi à Devoxx France 2012

Cet article a été écrit par Emmanuel Peru, Jeoffrey Haeyaert, Azize Elamrani, Emmanuel Diquas et François Descamps

Conférences

De Runnable et synchronized à parallel() et atomically() par José Paumard

Les sessions débutent très tôt et nous avons commencé par la présentation de José Paumard intitulée « De runnable et synchronized à parrallel() et atomaticaly() ». Ce docteur, maître de conférence, développeur indépendant, membre actif du ParisJug capte très vite son auditoire et nous emmène sur les chemins parallèles.

On part d’un résumé sur l’évolution des processeurs ces 20 dernières années où nous sommes passés des processeurs mono-cœur au multi cœurs (8 processeurs sur les pc grands public) et dans le futur des centaines de milliers de cœurs : processeurs exascale.

Pour le développeur, qui dit multi-cœur, dit multithread, dit meilleurs performances, mais dit aussi problème de concurrence et de synchronisation.

José avance deux solutions :

1) Synchroniser les modifications avec les problèmes de performances que l’inter attente des
cœurs peut engendrer.
2) Ne plus modifier les variables : comme on s’en doute, cela n’est évidemment pas possible.

Nous passons ensuite en revue toute les techniques actuelles tel que l’utilisation de java.util.concurrent.*, des locks, des sémaphores, des Atomic, les BlokingQueue, les CopyAndWriteArrayList, les Actors,le Fork/Join de JAVA 7, les Parrallel Array…

Cependant la conclusion, de cette conférence est que le parallélisme n’est pas une fin en soit. Un récent concours lancé par Heinz Kabutz pour définir Fibonacci 1 milliard a vu des temps de réponses passer de 5600s (sur 8 cœurs) à 3300s (sur 4 cœurs) pour finir à 51s (sur un cœur) avec uniquement des améliorations d’algorithme et une meilleure utilisation d’autres api.

Une chose à retenir : avant de paralléliser pour améliorer les performances, demandez-vous « Est-ce que mon algorithme est le bon ? »

Android, a quick course par Mathias Seguy

Cette conférence de M. Seguy emboîte bien le pas à la précédente, on ne s’ennui pas et on apprend plein de choses. On commence donc par un résumé de l’avancée des smartphones et la pénétration sur le marché d’Android. Le constat est là : nous, développeurs, allons devoir à un moment ou un autre coder des applications mobiles. Et ceci pour deux raisons : tout le monde en fait (et en veut) et parce que c’est fun aussi !

3 commandements nous sont enseignés par M. Seguy :

1. Tu ne trahiras pas la confidentialité des données de ton utilisateur, autrement dit on est obligé de déclarer ce qu’on veut pouvoir lire, modifier et partager.
2. Tu respecteras les ressources de ton utilisateur : pas d’application de 100Mo à télécharger, pas de gaspillage de la mémoire vive, pas de surstockage, pas d’utilisation outrancière de la batterie. De toutes façon, si tel est le cas, l’utilisateur zappera vite l’application.
3. Tu respecteras les bonnes pratiques et les standards. Vous allez me dire, comme dans tout développement qu’importe la technologie, mais c’est encore plus vrai avec Android, car on a quand même eu plus d’une dizaine de versions ces 3 dernières années, dont 2 majeurs. La rétro-compatibilité est donc le maître mot.

Le reste de la conférence est un tutoriel géant dans lequel on commence par l’Activity, les Services, les ContentProvider, les fichiers principaux… : le cœur de l’application. Puis on voit tout ce qui gravite et enrichit l’application :

• Le cycle de vie (à prendre en compte dès le début).
• Les ressources.
• Le graphisme
• La compatibilité des devices (parfois il faut prévoir plus d’une centaine de configuration entre
• versions de l’os et résolution d’écran !)
• La fragmentation (les versions incessantes d’Android qui sont à la fois une chance et un fardeau).
• La base de données
• Les fichiers
• Les capteurs
• …..

On abordera enfin les tests, qui apparaissent encore plus important que dans une application standalone (multi devices oblige) et le déploiement sur un émulateur et enfin chez Google.

A la fin, si on n’en a pas encore fait, on ne pense qu’à une chose : développer sa petite application smartphone, même si elle ne fait pas grand-chose et pourquoi pas avoir un destin à la Instagram !

JDK8 LAMBDA par Guillaume Tardiff

A Devoxx, on n’attend pas qu’un framework ou une version de JDK sorte officiellement pour la tester, alors même si la date officielle est septembre 2013, Guillaume Tardif nous présente une avancée majeure du JDK8 : les lambdas.

Rien à voir avec les maths, les lambdas sont une nouvelle manière d’utiliser les collections qui va amener un concept révolutionnaire : des implémentations dans une interface !

Tout d’abord un exemple simple celui d’une Collection qu’on connait tous :

[java]
List<String> names = new ArrayList<String>();
names.add("Pierre");
names.add("Paul");
names.add("Jacques");
// Affiche tous les noms.
names.foreach(s -> System.out.println(s));
// Retourne une collection avec uniquement les prénoms de plus de 4 caractères.
names.filter(s -> s.length() > 4);
// Une petite combinaison des deux
names.filter(s -> s.length() > 4).foreach(s -> System.out.println(s));
[/java]

On peut aussi utiliser une expression Lambda pour implémenter le code d’une interface :

[java]
interface Action{
void execute(String s);
}
Action helloWorld = s -> System.out.println(s);
helloWorld.execute("Hello World");
[/java]

Ca marche pour les interfaces qui n’ont qu’une seule méthode. Pour éviter de remettre en cause des années de développement qui ont utilisé les api collections et leurs implémentations, JDK8 introduit donc l’implémentation par défaut :

[java]
interface Action{
void execute(String s);
void executeUpperCase(String text) default {
execute(text.toUpperCase());
}
}

[/java]

C’est assez déconcertant, mais après tout, le changement est toujours bon à prendre.

Cela introduit donc dans Java8, l’héritage multiple puisqu’on va pouvoir au sein d’une classe profiter de l’implémentation par défaut de méthode de plusieurs interfaces.

Normalement, une question vous taraude : quelle implémentation par défaut est utilisée si une classe implémente deux classes qui ont la même signature de méthode ?

La réponse est simple : le compilateur vous demandera de choisir quelle implémentation vous voulez !

Réduire la pression sur l’allocation mémoire : le prochain pas dans l’optimisation des performances de la JVM par Benoit Perroud et Olivier Lamy

Cette session intitulée “Réduire la pression sur l’allocation mémoire : le prochain pas dans l’optimisation des performances de la VM” nous a été présentée par Benoît Perrou et Olivier Lamy à travers l’utilisation de l’API Apache Memory.

Benoît Perrou a introduit sa présentation en nous rappelant que le développeur est souvent confronté a des problèmes de performances. Certains problèmes peuvent être résolus par la mise en place de caches qui permettent de conserver les données dont le calcul s’avère coûteux en ressources ou en temps. Ces données sont stockées, dans la plupart des cas, dans le Heap. Mais celui-ci n’est pas infini…

Qu’est ce qu’Apache Direct Memory (DM) ?

Apache DM a pour but d’étendre l’utilisation d’un cache à la mémoire physique d’une machine.

Pourquoi un tel besoin ? Les principaux objectifs sont :

• Réduire la mémoire du heap consommée en déportant une partie dans la mémoire physique de la machine,
• Réduire la charge du Garbage Collector : Oliver Lamy  nous a rappelé la problématique de libération de la mémoire par le Garbage Collector. Ce dernier, bloque l’intégralité du programme pour s’exécuter et  peut dégrader considérablement les performances des applications.

2 types de caches. 

Olivier Lamy nous a ensuite rappelé qu’il existe 2 types de caches :

• onheap : les données sont stockées dans le tas qui est géré par la JVM. L’avantage est qu’il n’y a pas de pénalité lors de l’accès aux données. L’inconvénient réside dans la nécessité à faire tourner les GC pour libérer la mémoire lorsque les données sont périmées.
• offheap : Les données sont stockées dans la mémoire physique qui n’est pas maintenue par la JVM. La taille du heap reste ainsi maîtrisée et on dispose de d’avantage de mémoire pour stocker les données des applications. Les contres parties sont le coût de la sérialisation / désérialisation des objets à l’écriture et la lecture des données du cache offheap.

Apache Direct Memory utilise de façon intelligente les 2 stratégies de stockage.

Une architecture technique reposant sur des standards. 

Apache DM a été développé en couches, chacune ayant un rôle définit :

• Allocation de la mémoire (ByteBuffers),
• Gestion des références d’objets.
• API de haut niveau pour l’utilisation du cache.

Les 2 speakers nous ont ensuite expliqué la stratégie d’allocation mémoire utilisée.  Apache Direct Memory repose sur l’utilisation d’objets ByteBuffer présents en standard depuis le JDK 1.5. Ces ByteBuffers sont alloués en masse puis découpés à la demande pour stocker les données.

Et à l’utilisation, comment ça se présente ?

Apache DM se présente sous 2 formes :

• embarquée : il est possible d’embarquer les librairies directement dans son application (webapp, …) et utiliser l’API de manière classique en Java (comme on peut le faire avec EHCache).
• déployé : Apache DM peut être déployé sur un serveur. Il expose une interface REST permettant d’effectuer les opérations classiques (PUT, GET, DELETE, …). Le cache se trouve ainsi centralisé et mutualisé pour n’importe quel type d’applications, Java ou non (du fait de son interface REST).

Apache DM est utilisable avec EHCache ou Ououups.

Les prochaines étapes. 

Avant de conclure, les 2 speakers nous ont présentés les prochaines étapes :

• Implémenter la JSR 107,
• Réaliser des benchmarks pour valider l’efficacité du système et le comparer à d’autres solutions (ex : BigMemory de terracotta),
• Intégration dans Cassandra, Lucene et Tomcat,
• Permettre la modification dynamique de la taille de cache (définie une fois pour toute à l’initialisation),
• Offrir des outils de monitoring et de management.