Est le CLR une machine virtuelle?

J'ai lu un livre qui se réfère à l' .net CLR comme une machine virtuelle? Quelqu'un peut-il justifier cela? Qu'est-ce que la raison nous avons besoin de la notion de machines virtuelles sur certaines plates-formes de développement?

N'est-il pas possible de développer un cadre autochtone [sans machine virtuelle] qui est entièrement orienté objet et aussi puissant .net?

Le livre qui fait référence à CLR que la machine virtuelle est "Professionnel .Net Framework 2.0".

  • C'est vraiment juste un argument de plus à ce qu'est une "machine virtuelle" est. Notez que les "indigènes" jeu d'instructions x86 peut être considéré comme une machine virtuelle du jeu d'instructions, interprété par le PROCESSEUR. Donc, si le CLR s'exécute sur une machine virtuelle, est-il possible pour elle de ne pas être considéré comme une machine virtuelle?
  • Le CLR ne fonctionne pas sur une "machine virtuelle". Le CLR est un juste-à-temps compilateur et un garbage collector. Lorsque le CLR doit invoquer dans une bibliothèque en C il n'ont pas les frais généraux qui JNI n'parce qu'il est déjà en code natif, ce qui il a à faire est d'appuyer les arguments sur la pile et de sauter à la méthode. Alors que Java a à faire toutes sortes de cher de gymnastique pour faire que le scénario de travail, résultant en une très lente pont en code natif.
  • fonctionne très bien à l'intérieur de VMware, VirtualBox, Virtual PC, etc, donc je ne sais pas pourquoi vous faites un universel prétendre qu'il ne s'exécute pas sur les ordinateurs virtuels. Mais je suppose que vous vouliez dire, si CLR est elle-même une VM, pas de savoir s'il s'exécute sur le dessus de l'un. Comme vous le dites, le CLR a un compilateur JIT et un garbage collector. Mais vous avez raté le vérificateur. Et le modèle de sécurité. Et sa propre implémentation des threads distincts de l'OS. Et son propre chargeur. De l'exécution et de l'introspection, y compris un système sophistiqué de débogage de l'API. C'est certainement une machine virtuelle.
  • Il choisit de partager beaucoup de choses avec la machine physique, telles que l'adresse de l'espace (qui est virtualisé sur la machine physique de toute façon), afin de réduire la quantité de travail que p/invoke a faire.... mais selon les types impliqués p/invoke fait beaucoup de travail, et même pour les types simples, il est nulle part près d'aussi simple que de "pousser les arguments sur la pile et de sauter". Chaque géré/native de transition implique de changer le collecteur d'ordures de l'état, à la broche de paramètres passés par référence, et aussi pour permettre au gouvernement pour mettre en pause le thread sur le retour en code managé.
  • Voigt - oui, si vous ajoutez un groupe de travail, je n'ai jamais spécifié, alors il n'y a plus de travail à faire pour l'appel des indigènes, mais si vous utilisez uniquement blittable types de la différence entre le CLR et Java devient tout à fait évident. Sans compter poussant les arguments sur la pile, un calli instruction compile à 6 ASM instructions. Je doute sérieusement une interprétation d'une méthode Java pouvez le faire n'importe où près aussi efficace. L'interprétation est ce qui fait une course de méthode Java "virtuel", tandis qu'un exécutant CLR méthode est aussi réel que tout compilé en C++ méthode.
  • Mais je n'ai pas "ajouter", le CLR toujours fait ces choses et vous avez choisi de les laisser hors de votre mise en œuvre à l'appui de votre description d'une très fine couche. Mais le code en cours d'exécution avec le CLR est "géré" pas "natif", et géré/native transitions sont compliquées bêtes. Même si une grande partie du travail est effectuée à l'aide de la table de recherches (le même type de démarche que zéro charge la gestion des exceptions), de sorte qu'il n'apparaisse pas sur le site d'appel, le fait demeure que, pour chacune de ces transitions a le potentiel pour être un point de synchronisation avec le garbage collector.

InformationsquelleAutor this. __curious_geek | 2009-10-14
  1. 92

    Il y a beaucoup de fausses idées ici. Je suppose que vous pourriez penser .Net comme une machine virtuelle si tu le voulais vraiment, mais regardons comment le .Net Framework gère votre code. Le scénario typique ressemble à ceci

    1. Vous écrire .Net programme en C#, VB.Net, F#, ou d'un autre langage compatible.
    2. Que le code est compilé vers le bas à un niveau Intermédiaire de la Langue (IL), ce qui est similaire à Java bytecode, qui est distribué dans les machines des utilisateurs.
    3. Un utilisateur final utilise le programme pour la première fois sur un ordinateur avec la bonne version de .Installée nette
    4. Voit l'ordinateur c'est une .Net de l'assemblée plutôt que de "raw" en code machine, et les transmets le compilateur JIT
    5. Le compilateur JIT compile le IL a de code machine natif.
    6. Le code natif est enregistré en mémoire pour la durée de ce programme à l'exécution.
    7. Enregistrées en code natif est invoqué, et IL n'a plus d'importance.

    Il y a quelques points importants ici, mais le grand est que à aucun moment aucun code jamais interprété. Au lieu de cela, vous pouvez le voir dans l'étape 5 qu'il est compilé en code natif. Cette énorme de différence que de les charger dans une machine virtuelle, pour plusieurs raisons:

    1. Le code compilé est exécuté par le processeur directement plutôt que de les interpréter ou traduits par un logiciel supplémentaire de la couche d'abstraction, qui devrait être plus rapide.
    2. Le compilateur JIT peuvent profiter des optimisations spécifiques à la machine à l'exécution du programme, plutôt que de s'installer pour un plus petit dénominateur commun.
    3. Si vous le souhaitez, vous pouvez même pré-compiler le code et dans l'essence de masquer l'étape 5 de l'utilisateur complètement.

    Je suppose que vous pourriez appeler cela une machine virtuelle, dans le sens de la Gigue résumés loin les détails de la machine réelle de la part du développeur. Personnellement, je ne pense pas que c'est vraiment bon, parce que pour beaucoup de gens, une machine virtuelle implique un temps d'exécution de l'abstraction à l'écart de code natif pour .Net les programmes d' n'existe pas.

    Un autre point important concernant l'ensemble de ce processus qui distingue vraiment à part une "machine virtuelle" de l'environnement, c'est que c'est seulement le typique processus. Si vous le voulez vraiment, vous pouvez pré-compiler un .Net de l'assemblée avant de la distribution et de déployer du code natif directement à l'utilisateur final (indice: il est plus lent dans l'ensemble au cours de la vie du programme, parce que vous perdez de la machine-optimisations spécifiques). Bien sûr, vous avez encore besoin de la .Net runtime installé, mais à ce point c'est vraiment pas très différente de toute autre exécution de l'API, c'est plus une collection dll avec une belle API, vous pouvez lier contre, comme vous avez pu le VB ou C temps de fonctionnement de Microsoft est également livré avec Visual Studio. Ce genre de faut de l'IL de l'image, rendant la VM moniker beaucoup plus difficile à justifier. (Je dis "genre de", car IL est toujours déployé et utilisé pour vérifier le même code, mais il n'est jamais lui-même touché pour l'exécution).

    Un autre révélateur est le manque d'une VM processus. Lorsque vous exécutez votre application, il n'y a pas de commune "bac à sable" processus qui s'exécute. A comparer avec Java, où si vous ouvrez le gestionnaire des tâches lorsqu'un programme est en cours d'exécution, vous verrez un processus spécifiquement pour la machine virtuelle Java, et l'application du processus réel est un fil à l'intérieur de l'espace créé par la machine virtuelle. Dans .Net, vous voyez l'application du processus dans le gestionnaire des tâches de Windows directement.

    En résumé: on pourrait dire qu'IL + CLR + JIT, ensemble, faire en quelque sorte une machine virtuelle. Personnellement, je ne le pense pas, mais je ne vais pas discuter avec vous si vous croyez que. Le point que je veux faire, c'est que lorsque vous dites à quelqu'un qu' .Net s'exécute dans une machine virtuelle avec aucune autre explication, l'idée que vous communiquez à personne, elle est "interprété bytecode dans un processus hôte." Et c'est tout simplement faux.

    • Avez-vous une référence sur l'élément 3 à partir de votre deuxième liste? Je n'ai jamais rien vu qui dit que la pré-JITted code est enregistré, sauf lorsque NGEN a été invoquée.
    • Aussi, en expliquant la nécessité de la Contrainte de l'Exécution de Régions si le JITting tous se passe une fois et une seule fois... msdn.microsoft.com/en-us/library/ms228973.aspx
    • JITted code est enregistré dans la mémoire, ce qui est perdu lors de l'application existe. Le code est re-JITted la prochaine fois que l'application est exécutée (ou, plus précisément, lorsqu'un nouveau processus utilise le code).
    • Je suis d'accord, c'est ma compréhension aussi
    • Vous semblez dire que si il ne veut pas le faire tout exactement de la même manière que Java est le cas, il n'est pas une Machine Virtuelle. Je pense que c'est la plus grande chose que je suis en désaccord avec vous à ce sujet, parce qu'il tend à être une définition circulaire.
    • Joel, selon vos commentaires, j'ai le sentiment que vous croyez que le compilateur JIT compile une fois pour toutes le IL code en code natif lorsque l'application démarre, puis s'arrête brusquement. C'est tout simplement faux, le JIT compile des méthodes à la volée à chaque fois que le flux d'exécution l'exige. Aussi, il y a une VM processus. C'est le CLR qui est en cours d'exécution de votre application. C'est certainement un bac à sable de l'environnement, avec une table, un modèle de sécurité, un service de métadonnées. L'exécution de l'application est juste nommé d'après l' .exe parce que la Fenêtre du chargeur de PE sait déléguer à la CLR .net binaires.
    • Aussi, NGEN code généré s'exécute à l'intérieur d'un CLR - ce n'est pas de créer un fichier exécutable natif qui utilise CLR/.NET comme une "collection (de) dll avec une belle API, vous pouvez lier contre" qu'il enregistre le code natif qui serait généré par le JIT.
    • Je ne crois que oui. Complément d'enquête montre que c'est seulement vrai si vous utilisez ngen ou si vous installez l'assemblage de la GAC. Là où j'en suis, à la fin nous devons mettre plus de choses dans le GAC et donc, ce n'est pas très large, mais je me rends compte qu'il n'est pas vrai pour tout le monde et donc, je vais mettre à jour ma réponse pour refléter cela.
    • non, je ne pense pas qu'il doit faire tout le même que Java sur une machine virtuelle, mais je dois avoir certaines attentes quand j'entends le terme "VM" pour ce contexte .Net tout simplement ne pas être à la hauteur. Je pense qu'il est trompeur de dire aux autres que .Net s'occupe de "l'intérieur" d'une machine virtuelle, d'autant que c'est généralement utilisé pour faire une distinction de code natif pour .Net n'existe pas. SI il y a une VM impliqués (quelque chose que j'ai déjà admis, vous pourriez faire un cas pour), c'est seulement à partir d'un pré-traitement de point de vue et pas quelque chose que votre code s'exécute "à l'intérieur".
    • J'ai en grande partie d'accord avec vous, et cette déclaration doit être "c'est comme une collection de dll..." C'est censé être une abstraction: une façon simple de penser à elle. Répare. Je suis en désaccord, cependant, que quelque chose s'occupe de "l'intérieur" de la CLR. "Par-dessus" serait plus correct.
    • encore toute votre dernier paragraphe est faux. Windows PE loader commence le CLR, qui lui-même démarre le programme au sein de sa commande, de la mémoire et de la sécurité sage. L'intérieur est certainement utilisable. C'est juste un hack pour éviter un lanceur à la java, Rotor ou mono. Mais le .net EE (moteur d'exécution) contrôle la façon dont le programme fonctionne.
    • Yep. L'en-Tête PE redirection est un truc pour l'amorçage de la CLR (mscoree) qui est, par tous les moyens, de l'exécution de votre .Net application. En outre, comme JB dit, JIT n'est pas faite une fois pour toutes, et certains JITted méthodes peuvent même être jeté et rejitted à un moment plus tard. Je suppose que les idées fausses sont dans l'oeil du spectateur.
    • Joel, votre réponse est à la suite de la MS de plomb. L' .net CLR est l'évolution de l'arrêt de la JVM. "IL + CLR + JIT" faire de l'égalité une machine virtuelle lorsque la fonction de l'équipe de la sortie est de reproduire le CLR de la fonctionnalité. Je n'apprécie pas ton étrange attaque sur un bien répondu à la question, y compris en apportant un tas d'affirmations re: ma réponse qui n'ont pas encore été répondu et semblent être de "mauvais" sur votre partie. L'OP considère que la JVM d'une machine virtuelle, de sorte que le .Net CLR est aussi une VM. Soit ni ou deux d'entre eux sont des Machines Virtuelles, car non seulement ils sont fonctionnellement identiques, l'un dérive de l'autre.
    • Vous faites le point (1) sur JIT code "plus rapide" n'est pas interprété plus loin. Ce qui est vrai, c'est un peu trompeur. Le rendement du code est plus proche de VM performance que, par exemple, C classiques projets. La différence est que le JIT de sortie contient beaucoup plus de temps d'exécution des contrôles, tapez-les contrôles de sécurité, et surtout beaucoup plus d'allocations dynamiques que les typiques C projet. Ma comparaison n'est pas destiné à être une comparaison de la valeur, mais plutôt sur cet angle: JIT sortie effectue comme VM code et non pas comme le code écrit à la non-VM API, à la fois de la vitesse et de la sécurité. C'est comme une machine virtuelle.
    • Sujet n ° 3, cette référence indique que seulement NGEN avais code est enregistré: msdn.microsoft.com/en-us/magazine/cc163655.aspx ", Notez le subtil compromis ici. À l'aide de NGEN moyens de négociation de la consommation CPU pour plus d'accès disque, puisque le natif de l'image générée par NGEN est susceptible d'être plus grande que la MSIL image. Vous demandez peut-être si cela pourrait nuire à démarrage à froid car elle entraîne une augmentation de l'activité du disque. Fait intéressant, le CLR de la Performance de l'équipe a observé que si la compilation JIT est complètement éliminé, le démarrage à froid de temps, généralement, d'améliorer."
    • Par les "discontinued JVM", je veux dire l'arrêt de la Machine Virtuelle Java de Microsoft.
    • "l'idée que vous communiquez à personne, elle est "interprété bytecode dans un processus hôte." Et c'est tout simplement faux". Je ne pouvais pas être plus d'accord. Ce n'est pas, à mon avis, la définition d'une Machine Virtuelle.
    • Vous écrivez "je pense que le plus révélateur chose, cependant, est l'absence d'une VM processus de" <-- eh Bien, selon linuxpoison.blogspot.co.royaume-uni/2010/11/... Pour compiler gmcs hello.cs et voici le kicker, pour exécuter mono hello.exe qui ressemble à un processus en cours d'exécution, il m'
    • Hmm, vous pouvez charger une .Net DLL dans un processus natif. Je peux écrire un exe Brut de l'Assemblée pour les architectures X86, qui évoque à la .Net CLR et le fait de charger dans mon pays natal, l'assemblée EXE, alors je peux prendre que la poursuite et de la charge .Net Dll dans le processus, une fois que le CLR est chargé, et de cette façon j'ai un natif processus en cours d'exécution .Net code. Vous pouvez également écrire Natif win32 dll et exe en C++ dans un mélange d'CLR mode. Vous pouvez écrire une dll C++ qui a un MANGER avec exporté native des fonctions, et un .Net referencable DLL dans une DLL. Une dll que vous pouvez utiliser GetProcAddress sur, et de référence dans .Net code.
    • L' .net framework est juste une bibliothèque, écrit en mode natif en C/C++. Puis un ajout de Format PE a été faite pour définir si une dll ou exe est .Net code ou pas et contient MSIL. Le chargeur de windows, en effet, JIT compiler toutes exécution de code en code machine natif quand il le charge. La seule chose qu'il fait à la demande est un code qui n'était pas référencé. E. g. si le code charge un autre DLL suite de la pipe comme un résultat d'une action de l'utilisateur ou de quelque chose, alors qui sera JIT compilé à la demande. Maintenant .Net Native est sorti, et avec qui vous pouvez compiler votre code et le .Net régions, on utilise en code natif.

    InformationsquelleAutor Joel Coehoorn
  2. 24

    Similaire à la Machine Virtuelle Java (JVM), l' .net CLR est un byte-code de l'interprétation de la machine virtuelle.

    La JVM interprète des programmes qui contiennent java byte codes et les .net CLR interprète des programmes qui contiennent ce que Microsoft appelle "le Langage Intermédiaire" des instructions. Il y a des différences entre ces octets de codes, mais les machines virtuelles sont similaires et aspire à fournir des fonctionnalités similaires.

    Ces deux machine virtuelle implémentations ont la possibilité de compiler leur entrée bytecode pour le langage machine de l'ordinateur qu'ils sont en cours d'exécution sur. Ceci est appelé "Juste À Temps de Compilation (JIT)" et le code de sortie produite est appelée "JIT code." Parce que le JIT code contiennent des séquences d'instructions en langage machine du PROCESSEUR de l'ordinateur, ce code est parfois désigné comme "natifs" du code.

    Cependant, JIT code est qualitativement et quantitativement différente de code natif, comme expliqué ci-dessous. Pour cette raison, cet article considère JIT code pour être rien de plus qu'un natif de mise en œuvre de la Machine Virtuelle lors de l'exécution d'un particulier bytecode programme.

    Une caractéristique que ces deux Machines Virtuelles (VMs) aspire à fournir est de la sécurité dans le formulaire de prévenir un certain nombre de dangereuses erreurs de programmation. Par exemple, le titre de ce forum d'un site web, stackoverflow, est inspiré par un tel type de dangereux erreur qui est possible en code natif.

    Afin d'assurer la sécurité et la sécurité de l'exécution, le VMs de mettre en œuvre la sécurité de type à la "Machine Virtuelle" de niveau. Les affectations de mémoire virtuelle sont nécessaires pour stocker le type de données qui est tenue à cet emplacement de la mémoire. Par exemple, si un nombre entier est poussé sur la pile, il n'est pas possible de la pop un double de la pile. C-style "unions", sont interdites. Les pointeurs et l'accès direct à la mémoire sont interdites.

    Nous ne pouvions pas obtenir les mêmes avantages en imposant un langage orienté objet-cadre sur les développeurs si le résultat est un fichier binaire natif comme un fichier EXE. Dans ce cas, nous ne serions pas en mesure de distinguer entre les binaires générés à l'aide du cadre et des Exe généré par un utilisateur malveillant employant d'autres sources que le cadre.

    Dans le cas de la VMs, le type de sécurité est appliquée au "niveau le plus bas" que le programmeur est autorisé à accéder. (En négligeant pour l'instant qu'il est possible d'écrire géré en code natif, ce qui est.) Par conséquent, aucun utilisateur ne rencontrerez une application qui effectue l'une des opérations dangereuses qui nécessitent un accès direct à la mémoire des emplacements et des pointeurs.

    Dans la pratique, l' .net CLR une manière d'écrire du code natif qui peut être appelé par .net "géré" du code. Dans ce cas, la charge est sur le code natif à l'auteur de ne pas faire du pointeur et de la mémoire des erreurs.

    À la fois comme la JVM et .net CLR effectuer la compilation JIT, soit VM crée en fait un natif binaire compilé à partir du bytecode fourni. Cette "JIT code" effectue plus rapidement que la VM est l'interprète de l'exécution, parce que même le langage machine code produit par JIT contient toutes les VM de sécurité vérifie que l'ordinateur virtuel effectuer. En conséquence, l'équipe de code de sortie n'est pas aussi rapide que le code natif qui seraient normalement pas contenir de nombreux au moment de l'exécution des contrôles. Toutefois, cette vitesse de la performance inconvénient est échangé pour une amélioration de la fiabilité, y compris la sécurité; en particulier, l'utilisation de non initialisé de stockage est empêché, de sécurité du type de missions est appliquée, de la portée de la vérification est effectuée (donc pile et tas dépassements de la mémoire tampon empêché), objet des durées de vie sont gérées par la collecte des ordures, l'allocation dynamique est de type sécurisé. Un environnement d'exécution de ce moment de l'exécution comportement de contrôle, la mise en œuvre de la spécification d'une machine virtuelle et n'est guère plus qu'un langage machine de la réalisation d'une machine virtuelle.

    • Solide détaillée instructif réponse, mais j'espère que vous ne m'en voudrez pas si je sélectionne un nit. Un débordement de pile est tout à fait possible dans le code managé: pour reproduire ce, à créer et appeler la méthode suivante: public void f() { f(); }. La différence tend à être que les erreurs sont de plus en plus prévisible et moins exploitable (ceci est lié à la sécurité de type, l'une qui a pour effet d'empêcher que les données soient accidentellement exécuter du code). Par exemple référence à un mauvais pointeur en C a des résultats imprévisibles; mais déréférencement null sur la JVM ou CLR en toute sécurité et de façon prévisible vous donne une exception. Toutes mes excuses pour pédantisme!
    • C'est un autre genre de débordement de pile, mais je vois ce que tu veux dire. Je faisais allusion à la dépassement de mémoire tampon de la pile, pas d'épuisement de la pile elle-même. Je pense que le nom de ce site web fait également référence à l'ancienne, et pas le dernier, mais c'est peut-être juste mon point de vue. Généralement, basée sur la pile dépassements de la mémoire tampon sont beaucoup plus intéressant que l'épuisement de la pile (ou de la machine virtuelle à pile), de sorte que c'est généralement ce que les gens veulent dire quand ils écrivent "stack overflow" même si, techniquement, votre interprétation peut également être correcte. Mais merci pour le commentaire. 😉
    • C'est tout simplement faux. .Net langues sont compilées à l'IL, qui est similaire à java byte code, et c'est la qu'IL est distribué sur les ordinateurs des utilisateurs pour l'exécution. La différence est qu'au lieu de charger le bytecode dans une machine virtuelle pour l'exécution .Net IL est compilé en code natif avant l'exécution. Aucune machine virtuelle en tant que telle est déjà chargé.
    • sûrement, c'est la compilation en code natif est un détail sans importance? Une future version du CLR qui a eu un éclair interprète pourrait passer à l'interprétation au lieu de cela, et personne n'aurait besoin de savoir qui fait...
    • on pourrait dire la même chose à propos de java, le passage à une native mode compilé. Si ils l'ont fait, vous devriez voir beaucoup de marketing de bruit à propos de "perdre la VM". De Plus, .Net vous donne la possibilité de pré-compiler si vous voulez vraiment (indice: c'est plus lente en moyenne sur la durée de vie d'un programme), qui prend un peu la IL hors de l'image.
    • Je ne pense pas que vous. Les développeurs ont encore serait la cible de la Machine Virtuelle. Je suppose que nous travaillons à partir de définitions différentes de la Machine Virtuelle, mais à mon avis des détails tels que les compilation JIT ne sont pas pertinents.
    • Autre différence: l'équipe s'arrête avant au début de votre programme. Les gens ont tendance à penser de la VM comme un bac à sable pour vous de code, et avec .Net il n'y a pas de sandbox de l'environnement en cours d'exécution tandis que votre code ne.
    • Juste un peu de précision... JITting est au niveau de la méthode, de sorte que chaque méthode sera compilé juste avant, il est appelé pour la première fois. Donc, techniquement, la Gigue est appelé tout au long de l'exécution du programme, à chaque fois déjà souscrit non appelé la méthode est invoquée. La seule fois que la Gigue serait "shut down" est si chaque méthode et tapez votre code a déjà été accessible à la fois.
    • La JVM ne quelque chose de semblable - il nativement compile "très utilisé" segments de code, plutôt que de tout le code - java.sun.com/developer/onlineTraining/Programming/JDCBook/... - de la recherche pour "Adaptative d'optimisation" de "Juste-À-Temps Compilateurs"
    • Joel: QUOI? Bien sûr, IL est distribué aux utilisateurs puis JITed, de même que le bytecode JVM. En fait, c'est mon point de -- c'est fonctionnellement sur pied d'égalité (par conception) de bytecode JVM. En fait, Sun Java avait JIT avant MME de la JVM, IIRC. Elle avait deux avant CLR existé. Rappelez-vous MME de la JVM?
    • "C'est, sur l'ordinateur qui exécute le "interprétés" code de la VM réelles crée un natif binaire compilé à partir du bytecode fourni. "VM = CLR, le bytecode=IL, fourni="Envoyé à l'utilisateur"
    • La première phrase est fausse. IL n'est jamais interprété, compilé uniquement. Que Java a aussi un JIT ne change pas le fait que Java est spécifié dans les termes d'un interprète, et .NET est spécifié dans les termes d'un compilateur.
    • Aussi Joel le commentaire de "avec .Net il n'y a pas de sandbox de l'environnement en cours d'exécution tandis que votre code ne." est totalement faux.
    • Mais lorsque le CLR n'est pas à l'aide de JIT, n'est-il pas interpréter? Si non alors quelle est-elle?
    • Non, il n'a pas d'interprète de la logique. Quelles sont les fonctions dans le CLR faire à part JITting dépend de la fonction -- le comportement est déterminé par la fonction appelée, et non par le code de l'application. (Un interprète est une bibliothèque de fonctions dont le comportement dépend de l'application du code chargé)
    • Pour le pseudo-code binaire à exécuter, si il n'y a pas d'interprétation du code machine natif à tous, il doit être tout compilé en code machine natif. Si seulement une partie du code est JITd, puis le reste devra être compilé une autre façon. Que feriez-vous appel à la compilation du code qui n'est pas JITd? AOTd? Ou est le code JITd? Le CLR appelle le compilateur JIT de sorte qu'il ne peut pas être un AOT compilateur. Je suppose que la totalité du bytecode est JITd alors?
    • Oui, tout le bytecode est JITted avant qu'il s'exécute. Ce n'est pas une seule étape, cependant. Le compilateur JIT n'a vraiment exécuter en "juste à temps". Je ne sais pas exactement comment cela fonctionne, mais vous pourriez penser qu'un pointeur de fonction commence avec l'adresse du compilateur que la fonction elle-même. La première fois qu'il est appelé, le compilateur génère du code machine, et change le pointeur de sorte que le prochain appel de la direction pour le code machine.
    • Voigt - oui, un pré-jitted méthode contient un saut de sa propre compilation, la dernière étape est de remplacer cette "pré-JIT stub" avec le corps de la méthode, pousser les arguments sur la pile, puis aller à elle.

    InformationsquelleAutor Heath Hunnicutt
  3. 7

    La "Machine Virtuelle" partie se réfère au fait que .NET code est compilé en EXE et DLL comme "Intermédiaire" de l'Assemblée de la langue (IL) pour s'exécuter sur une machine virtuelle, par opposition à réel CPU langage d'assemblage. Puis, au moment de l'exécution de l'ILM est converti en CPU réel de l'assemblée pour l'exécution (appelé Just-in-time ou JIT compiler).

    Bien sûr, vous pourriez écrire un .NET compilateur de sorte qu'il serait compilé dans l'UC de l'assemblée de la langue au lieu de l'IL. Cependant, ce ne serait pas portable pour tous les Cpu - vous auriez à compiler une version différente pour chaque système d'exploitation/PROCESSEUR paire. Mais en compilant dans ILM, vous laissez la "Machine Virtuelle" gérer le PROCESSEUR et l'OS de choses spécifiques.

    • Je pense que tu veux dire IL, ou, plus correctement, CIL - Common Intermediate Language.
    InformationsquelleAutor noctonura
  4. 2

    Je suis un peu vieille école, j'ai donc appeler le CLR une machine virtuelle. Mon raisonnement est que le CLR assemble le code de l'ordinateur à partir d'un intermédiaire de bytecode, qui est ce qu'une machine virtuelle aussi.

    Les avantages de la CLR est principalement en raison de la façon dont il assemble le code machine qui utilise le runtime type d'informations.

    Vous pouvez développer un cadre autochtone aussi puissant que l' .NET framework à l'aide seulement de types natifs. La seule flexibilité que vous perdez, c'est la capacité à remonter le code natif si jamais vous avez le transport de votre programme à une autre plate-forme sans avoir à recompiler.

    • La création de la machine ciblée des instructions à partir d'une représentation intermédiaire s'appelle la compilation d'où je viens.
    InformationsquelleAutor Andrew Keith
  5. 2

    L'avantage de la CLR est la liberté d'écrire du code quel que soit le langage de programmation le développeur choisit, depuis que le code sera compilé vers le bas pour CLR avant d'être interprétées dans les appels natifs. L' .NET framework utilise cette compilation JIT pour traiter tout uniformément et de sortie des programmes de travail de la plate-forme en cours de déploiement sur, ce qui est absent de langages compilés.

    • Comment est-il mauvais? La machine virtuelle se traduit par CLR byte code en natif instructions du PROCESSEUR, n'est-ce pas?
    • Votre commentaire est juste: il compile (traduit) CLR "bytecode", appelé "Intermédiaire de la Langue" en code machine natif. Ce n'est pas l'interprétation. Dans l'interprétation, le programme est des données; le code de l'exécution des tests de conditions sur les données et les sauts à l'autre code dans le moteur d'exécution; l'instruction du processeur pointeur ne traverse code, qui existe dans le moment de l'exécution. Lors de la compilation, le programme s'est transformé dans une section de code qui est exécuté sur le processeur (bibliothèque d'exécution de code s'exécute toujours lorsqu'il est appelé par le programme compilé le code, mais pas tout le code de pré-existe à l'exécution).
    InformationsquelleAutor Ben Lakey
  6. 2

    Ni la machine, ni le CLR faire tout ce qui est sensiblement différente de ce que la plupart des "machines virtuelles" pour d'autres langues également. Moderne, ils utilisent tous JIT pour convertir les instructions (p-code, bytecode, langage intermédiaire d'instructions, appelez ça comme vous voulez) pour "natif de matériel de PROCESSEUR" instructions ("code machine.")

    En fait, la première "machine virtuelle" pour ce faire, il a la Causerie de la machine virtuelle. L'auteur de cette innovation, Peter Deutsch, surnommé "la traduction dynamique" au lieu du terme "JIT", qui a été popularisé par Java. Si la Causerie "d'exécution de l'environnement" va être appelé une "machine virtuelle" (et c'est ce qu'il est toujours appelé, alors, de tout et de tous les autres "temps d'exécution des systèmes" que font essentiellement la même chose aussi être considérées comme des "machines virtuelles."

    • La JVM utilise également les services d'un interprète afin d'exécuter du code; il n'est pas un pur modèle de compilation comme bureau .NET CLR. C'est sensiblement différent car .NET langage intermédiaire est conçu avec l'hypothèse de la compilation JIT -- alors que l'on pouvait écrire un interprète, le rendement est mauvais, bien pire que l'interprète de Java, où le bytecode format est optimisé pour l'interprétation.
    • Mais oui, c'est encore une machine virtuelle.
    InformationsquelleAutor user2809447
  7. 1

    Vous avez beaucoup de précieuses réponses, mais je pense qu'une chose n'a pas encore été mentionnés: la Modularité.

    Il est assez difficile d'exporter un OO classe de DLL native. Bien sûr, vous pouvez dire à l'éditeur de liens à l'exportation de la classe et de les importer ailleurs, mais c'est fragile; la Modification d'un seul membre privé dans une classe de rompre la compatibilité binaire, c'est à dire si vous modifiez un fichier DLL sans recompiler tous les autres modules, votre programme va planter horriblement lors de l'exécution.

    Il y a des moyens de contourner cela: Par exemple, vous pouvez définir le public des interfaces abstraites, dérivent de ceux et de l'exportation mondiale de l'usine des fonctions à partir de votre fichier DLL. De cette façon, vous pouvez modifier les détails de l'implémentation d'une classe. Mais vous ne pouvez pas déduire de cette classe dans une autre DLL. Et changer l'interface se différencie également de la compatibilité binaire, bien sûr.

    Je ne suis pas sûr qu'il y en est une bonne solution pour ce en code natif: Si le compilateur/linker crée code natif au moment de la compilation, il doit connaître l'exacte disposition de la mémoire des classes et/ou des structures qui sont utilisées dans le code. Si la dernière étape de compilation (génération de code natif) est retardée jusqu'à ce qu'une méthode est appelée pour la première fois, ce problème va tout simplement à l'écart: vous pouvez modifier une classe dans une assemblée, et aussi longtemps que l'équipe peut résoudre tous les membres au moment de l'exécution, tout fonctionne bien.

    En un mot: Si vous créez un monolithique unique-programme exécutable, vous pourriez probablement avoir plus de fonctions puissantes d' .NET avec un compilateur qui crée code natif. Mais les inconvénients d'avoir un compilateur JIT (installation du framework, un peu plus long temps de démarrage) vraiment ne l'emportent pas sur les avantages dans la plupart des cas.

    InformationsquelleAutor Niki