Qu'est-ce que la JVM algorithme d'Ordonnancement?
Je suis vraiment curieux de savoir comment la JVM de travail avec les threads !
Dans mes recherches sur internet, j'ai trouvé un peu de matériel sur RTSJ, mais je ne sais pas si c'est la bonne direction pour mes réponses.
J'ai également trouvé ce sujet dans le soleil, de forums, de
http://forums.sun.com/thread.jspa?forumID=513&threadID=472453,
mais ce n'est pas satisfatory.
Quelqu'un peut-il me donner quelques directions, matériel, articles ou suggestion au sujet de la JVM algorithme d'ordonnancement ?
Je suis également à la recherche pour plus d'informations sur les configurations par défaut de Java threads dans le planificateur de tâches, comme "combien de temps faut-il pour que chaque thread" en cas de temps de trancher. Et ce genre de choses.
J'apprécierais toute aide !
Merci !
OriginalL'auteur mrcaramori | 2010-05-12
Vous devez vous connecter pour publier un commentaire.
Il n'existe pas de Java Virtual Machine, JVM est une spécification, et il y a plusieurs implémentations, y compris la version OpenJDK et le Soleil version de celui-ci, entre autres. Je ne sais pas pour certains, mais je suppose que tout raisonnable JVM serait tout simplement d'utiliser le sous-jacent filetage mécanisme prévu par le système d'exploitation, ce qui impliquerait des Threads POSIX (pthreads) sur UNIX (Mac OS X, Linux, etc.) et impliquerait WIN32 threads sur Windows. Généralement, ces systèmes utilisent un round-robin de la stratégie par défaut.
oui, le terme "JVM" implique une seule JVM, et tout cela a un sens dans le contexte d'une discussion sur un cas particulier de la JVM (par exemple, le Soleil de la JVM HotSpot), il n'a pas de sens sans la détermination de particulier JVM est en cours de discussion.
Personnellement il m'arrive souvent de dire des choses comme "la JVM va charger la classe ..." ou "la JVM va faire en sorte, que ..." certainement fait référence à une mise en œuvre, bien qu'il n'est pas pertinent pour le débat, dont la mise en œuvre concrète dont je parle. D'autre part, quand je parle précisément le cahier des charges, alors que ce devrait être noté "La JVM spec spécifie, que...", ou quelque chose comme ça.
OriginalL'auteur Michael Aaron Safyan
Il ne le fait pas. La JVM utilise le système d'exploitation natif des threads, le système d'exploitation n'est que de la programmation, pas la JVM.
Hartung: true, en.wikipedia.org/wiki/Green_threads dit la JVM Hotspot a utilisé les threads natifs depuis la version 1.2 jours
non, l'article dit que le 1.1 de la JVM utilisée sur Solaris, et je me souviens d'entre eux étant utilisés par Linux JVM lorsqu'il s'appelait encore Blackdown, mais je suis assez sûr que Hotspot (qui est devenu une partie de la JVM que dans 1.3) n'a jamais utilisé de fils verts.
"Fils verts" sont un peu inutile sur les machines avec plus d'un thread matériel. Cependant, il existe un schéma (a été utilisé par JRockit, IIRC, pas sûr de savoir si cela ne fonctionne toujours), où il utilise un certain nombre de threads natifs, mais ils ne sont pas directement liés à des threads Java. Aurait pu être un particulier d'optimisation pour les systèmes 32 bits (vous vous rappelez?).
OriginalL'auteur Chris Dolan
Il y a un moment, j'ai écrit quelques articles sur la planification de thread du point de vue de Java. Cependant, sur la majorité des plates-formes, le filetage comportement dépend essentiellement de l'OS sous-jacent threading.
Avoir un look en particulier à ma page sur ce qui est La priorité des threads Java, qui explique comment Java niveaux de priorité de la carte à l'OS sous-jacent filetage priorités, et comment, dans la pratique, ce qui rend des fils de différentes priorités de son comportement sur Linux vs Windows. Une différence majeure discuté, c'est que sous Linux il y a plus de relation entre la priorité de thread et de la proportion de CPU alloué à un fil, alors que sous Windows, ce n'est pas le cas (voir les graphiques).
OriginalL'auteur Neil Coffey
Je n'ai pas les droits de commentaires tellement l'écriture est ici...
JVM appelle pthreads(généralement utilisé mécanisme de threading,d'autres variantes sont là) pour chaque demande correspondante. Mais la programmation est faite entièrement par l'OS hôte.
Mais c'est une approche privilégiée et il est possible de programmer ces threads par la JVM. Par exemple, dans Jikes RVM il y a des options pour remplacer cette approche de l'OS de la décision. Par exemple, dans les threads sont visés en tant que RVMThread et ils peuvent être programmées/manipulés à l'aide de org.jikesrvm.schedular les classes du package.
Pour plus d' référence
OriginalL'auteur Rorschach