Salut,
Envoyé par
iohack
Que l'on m'arrête si je me trompe mais pour moi, la JVM et l'implémentation du code n'ont aucun pouvoir sur la manière dont vont être répartis les Threads sur les différents processeurs. C'est le système d'exploitation qui gère ça.
C'est à la fois vrai et faux
Dans certaines implémentation, la JVM peut gèrer les threads elle-même...
Je m'explique : dans les systèmes Unix il existe un modèle de gestion de thread basé sur des processus lourds. Donc à chaque création de thread un nouveau processus est créé avec tout ce que cela implique (copie de mémoire et des ressources). Il me semble que cela simplifiait l'implémentation de la répartition des threads entre les différents processeurs, mais cela avait toutetois le désavantage de proposer des performances lamentables dans un environnement mono-thread...
Du coup les premières JVMs proposaient 2 gestions des threads :
- La première laissait toutes la gestion des threads au système d'exploitation.
- Alors que dans le second cas c'est la JVM qui "simulait" la gestion des threads avec un processus unique. C'est ce qu'on appelle les "green threads". Etant donné qu'il n'y a qu'un seul processus il est impossible de distribuer les tâches sur différents processeurs, mais par contre cela se révèle plus performant en mono-processeur car cela évite la création de plusieurs processus...
On pouvait utiliser les options -native ou -green de java pour passer de l'un à l'autre, par exemple :
java -native -jar MonJar.jar
Toutefois, la plupart des Unixes actuels propose un "vrai" modèle de thread basé sur des processus légers, ce qui rend obsolète les "green threads" de la JVM, mais il peuvent toutefois être utilisés sur certains systèmes "exotiques" qui ne proposeraient pas de gestion de thread...
Enfin, il me semble que lorsqu'il sont utilisé, le terme "green thread" est affiché dans la version de Java :
String version = System.getProperty("java.version");
a++
Partager