BT

Diffuser les Connaissances et l'Innovation dans le Développement Logiciel d'Entreprise

Contribuez

Sujets

Sélectionner votre région

Accueil InfoQ Actualités Propositions préliminaires pour la concurrence avec le JDK 9

Propositions préliminaires pour la concurrence avec le JDK 9

Favoris

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 du Compare 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 MethodHandles. 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.

Evaluer cet article

Pertinence
Style

Contenu Éducatif

BT