Doug Lea, ayant entre autres participé à la définition du modèle mémoire de Java (la JSR 133), au package java.util.concurrent
et au framework Fork-Join
de Java 7, a publié sur la mailing list concurrency-interest ses premières propositions en rapport avec la programmation concurrente pour le JDK 9.
Pour rappel, Java a été le premier langage industriel à spécifier son modèle mémoire. Ce modèle décrit comment les threads intéragissent à travers la mémoire partagée. La JSR 133 a redéfini le modèle mémoire initial de Java pour le corriger et permettre de nouvelles optimisations par le compilateur JIT. Ce modèle est effectif depuis 2004 et la sortie de Java 5.0.
Parmi les propositions, on trouve :
- des révisions et extensions du modèle mémoire, en particulier pour le clarifier et l'aligner sur le modèle mémoire des standards C11 et C++11
- des additions à java.util.concurrent et un meilleur support de la programmation asynchrone
- une amélioration du support par les JVM de
java.util.concurrent
, en particulier des outils pour les architectures à accès mémoire non uniforme (NUMA), un meilleur sondage de la mémoire et un support duCompare And Swap
(CAS) sur deux variables- un support des Value Types et un possible support des tableaux de structures, à priori basé sur les propositions de John Rose.
- une exposition dans le langage de primitives permettant d'accéder à des opérations telles que CAS et aux barrières sans passer par la classe
Unsafe
. Pour ce dernier point, la proposition de Doug Lea est d'ajouter une nouvelle syntaxe.volatile
qui exposerait des méthodes. Par exemple :
class Usage {
volatile int count;
int incrementCount() {
return count.volatile.incrementAndGet();
}
}
Ce dernier point est le sujet le plus polémique. Rémi Forax, ayant participé aux JSR 292 invokedynamic
et 335 sur l'ajout des lambdas à Java, critique le manque de flexibilité d'un ajout de syntaxe et propose à la place une API utilisant invokedynamic et des MethodHandle
s. Cette solution serait plus simple à optimiser pour les compilateurs JIT, et surtout permettrait de transmettre ce comportement en cas de références multiples plutôt que de devoir réimplémenter la même logique à chaque appel.