Вопрос

Как своего рода продолжение вопроса под названием Различия между байт-кодом MSIL и Java?, каковы (основные) различия или сходства в работе виртуальной машины Java по сравнению с тем, как работает виртуальная машина Java? .NET Framework Common Language Runtime (CLR) работает?

Кроме того, является ли .NET Framework CLR - это "виртуальная машина" или она не имеет атрибутов виртуальной машины?

Это было полезно?

Решение

Между обеими реализациями есть много общего (и, на мой взгляд:да, они обе «виртуальные машины»).

Во-первых, они обе являются виртуальными машинами на основе стека, без понятия «регистров», которое мы привыкли видеть в современных процессорах, таких как x86 или PowerPC.Оценка всех выражений ((1 + 1)/2) выполняется путем помещения операндов в «стек» и последующего извлечения этих операндов из стека всякий раз, когда инструкции (сложение, деление и т. д.) необходимо использовать эти операнды.Каждая инструкция помещает свои результаты обратно в стек.

Это удобный способ реализовать виртуальную машину, потому что почти каждый процессор в мире имеет стек, но количество регистров часто разное (а некоторые регистры являются специальными, и каждая инструкция ожидает свои операнды в разных регистрах и т. д.). ).

Итак, если вы собираетесь моделировать абстрактную машину, модель, основанная исключительно на стеке, является довольно хорошим способом.

Конечно, настоящие машины не работают таким образом.Таким образом, JIT-компилятор отвечает за выполнение «регистрации» операций с байт-кодом, по сути, планируя фактические регистры ЦП так, чтобы они содержали операнды и результаты, когда это возможно.

Я думаю, что это одно из самых общих черт между CLR и JVM.

Что касается различий...

Одно интересное различие между этими двумя реализациями заключается в том, что CLR включает инструкции для создания универсальных типов, а затем для применения к этим типам параметрической специализации.Таким образом, во время выполнения CLR считает List<int> типом, совершенно отличным от List<String>.

Под прикрытием он использует один и тот же MSIL для всех специализаций ссылочного типа (поэтому List<String> использует ту же реализацию, что и List<Object>, с разными приведениями типов на границах API), но каждый тип значения использует своя уникальная реализация (List<int> генерирует совершенно другой код, чем List<double>).

В Java универсальные типы — это чисто трюк компилятора.JVM не имеет представления о том, какие классы имеют аргументы типа, и не может выполнять параметрическую специализацию во время выполнения.

С практической точки зрения это означает, что вы не можете перегружать методы Java для универсальных типов.У вас не может быть двух разных методов с одинаковым именем, отличающихся только тем, принимают ли они List<String> или List<Date>.Конечно, поскольку CLR знает о параметрических типах, у нее нет проблем с обработкой методов, перегруженных специализациями универсальных типов.

В повседневной основе это то, что я замечаю больше всего между CLR и JVM.

Другие важные различия включают в себя:

  • В CLR есть замыкания (реализованные как делегаты C#).JVM поддерживает замыкания только начиная с Java 8.

  • В CLR есть сопрограммы (реализованные с помощью ключевого слова C# «yield»).JVM этого не делает.

  • CLR позволяет пользовательскому коду определять новые типы значений (структуры), тогда как JVM предоставляет фиксированный набор типов значений (byte, short, int, long, float, double, char, boolean) и позволяет пользователям определять только новые ссылки. типы (классы).

  • CLR обеспечивает поддержку объявления указателей и управления ими.Это особенно интересно, поскольку и JVM, и CLR используют реализации сборщика мусора со строгим сжатием поколений в качестве стратегии управления памятью.В обычных обстоятельствах сборщику мусора со строгим сжатием приходится очень тяжело с указателями, поскольку при перемещении значения из одной ячейки памяти в другую все указатели (и указатели на указатели) становятся недействительными.Но CLR предоставляет механизм «закрепления», позволяющий разработчикам объявить блок кода, внутри которого CLR не разрешено перемещать определенные указатели.Это очень удобно.

  • Самая большая единица кода в JVM — это либо «пакет», о чем свидетельствует ключевое слово «protected», либо, возможно, JAR (т.Java ARchive), о чем свидетельствует возможность указать jar в пути к классам и рассматривать его как папку с кодом.В CLR классы объединяются в «сборки», а CLR предоставляет логику для анализа и управления сборками (которые загружаются в «AppDomains», обеспечивая песочницы на уровне субприложений для распределения памяти и выполнения кода).

  • Формат байт-кода CLR (состоящий из инструкций MSIL и метаданных) имеет меньше типов инструкций, чем JVM.В JVM каждая уникальная операция (добавление двух целочисленных значений, добавление двух значений с плавающей запятой и т. д.) имеет свою уникальную инструкцию.В CLR все инструкции MSIL являются полиморфными (добавляют два значения), а JIT-компилятор отвечает за определение типов операндов и создание соответствующего машинного кода.Однако я не знаю, какая стратегия предпочтительнее.У обоих есть компромиссы.JIT-компилятор HotSpot для JVM может использовать более простой механизм генерации кода (ему не нужно определять типы операндов, поскольку они уже закодированы в инструкции), но это означает, что ему нужен более сложный формат байт-кода, с большим количеством типов инструкций.

Я использую Java (и восхищаюсь JVM) уже около десяти лет.

Но, по моему мнению, CLR теперь является лучшей реализацией почти во всех отношениях.

Другие советы

Ваш первый вопрос - сравнение JVM с .NET Framework - я полагаю, вы действительно вместо этого хотели сравнить с CLR. Если так, я думаю, вы могли бы написать небольшую книгу об этом ( РЕДАКТИРОВАТЬ: похоже, что Бенджи уже имеет :-)

Одним из важных отличий является то, что CLR спроектирована как независимая от языка архитектура, в отличие от JVM.

Еще одно важное отличие заключается в том, что CLR был специально разработан для обеспечения высокого уровня взаимодействия с собственным кодом. Это означает, что CLR должен управлять надежностью и безопасностью при обращении к собственной памяти и ее изменении, а также управлять сортировкой между структурами данных на основе CLR и собственными структурами данных.

Чтобы ответить на ваш второй вопрос, используйте термин & # 8220; виртуальная машина & # 8221; это более старый термин из мира аппаратного обеспечения (например, IBM & # 8217; виртуализация 360 в 1960-х годах), который имел в виду программную / аппаратную эмуляцию базовой машины для выполнения того же рода вещей, что и VMWare.

CLR часто называют " механизм исполнения " ;. В этом контексте это реализация IL-машины поверх x86. Это также то, что делает JVM, хотя можно утверждать, что между полиморфными байт-кодами CLR и типизированными байт-кодами JVM есть важное различие.

Таким образом, педантичный ответ на ваш второй вопрос: " no " ;. Но это действительно сводится к тому, как вы определяете эти два термина.

РЕДАКТИРОВАТЬ . Еще одно различие между JVM и CLR заключается в том, что JVM (версия 6) является очень неохотно освободить выделенную память обратно в операционную систему, даже там, где это возможно.

Например, предположим, что процесс JVM запускается и первоначально выделяет 25 МБ памяти из операционной системы. Затем код приложения пытается выделить ресурсы, которые требуют дополнительных 50 МБ. JVM выделит дополнительные 50 МБ из операционной системы. После того, как код приложения перестал использовать эту память, он будет собирать мусор, и размер кучи JVM уменьшится. Однако JVM будет освобождать выделенную память операционной системы только при определенных очень специфических обстоятельствах . В противном случае до конца срока службы процесса эта память останется выделенной.

CLR, с другой стороны, освобождает выделенную память операционной системе, если она больше не нужна. В приведенном выше примере CLR освободил бы память после уменьшения кучи.

Более подробную информацию о различиях можно найти в различных академических и частных источниках.Как только хороший пример Варианты дизайна CLR.

Некоторые конкретные примеры включают в себя:

  • Некоторые низкоуровневые операнды типизированы, например «добавить два целых числа», тогда как CLR использует полиморфный операнд.(т.е.fadd/iadd/ladd против просто добавить)
  • В настоящее время JVM выполняет более агрессивное профилирование и оптимизацию времени выполнения (т.Точка доступа).CLR в настоящее время выполняет JIT-оптимизацию, но не оптимизацию во время выполнения (т. е.замените код во время работы).
  • CLR не встраивает виртуальные методы, JVM это делает...
  • Поддержка типов значений в CLR, помимо «примитивов».

CLR и JVM являются виртуальными машинами.

.NET Framework и среда выполнения Java представляют собой связку соответствующих виртуальных машин и их библиотек. Без библиотек виртуальные машины довольно бесполезны.

Это не виртуальная машина. Платформа .net компилирует сборки в собственный двоичный файл во время первого запуска:

В вычислениях компиляция точно в срок (JIT), также известная как динамическая трансляция, представляет собой метод повышения производительности компьютерной программы во время выполнения. JIT опирается на две более ранние идеи в средах выполнения: компиляция байт-кода и динамическая компиляция. Он преобразует код во время выполнения до его естественного выполнения, например, байт-код в машинный код. Повышение производительности по сравнению с интерпретаторами происходит из-за кэширования результатов перевода блоков кода, а не просто переоценки каждой строки или операнда каждый раз, когда они встречаются (см. Интерпретированный язык). Он также имеет преимущества по сравнению со статической компиляцией кода во время разработки, так как он может перекомпилировать код, если это окажется полезным, и может быть в состоянии обеспечить гарантии безопасности. Таким образом, JIT может сочетать некоторые преимущества интерпретации и статической (опережающей) компиляции.

Некоторые современные среды выполнения, такие как Microsoft .NET Framework, большинство реализаций Java и последний ActionScript 3, используют JIT-компиляцию для высокоскоростного выполнения кода.

Источник: http://en.wikipedia.org/wiki/Just-in -time_compilation

Добавление .NET Framework содержит виртуальную машину, как и Java.

Лицензировано под: CC-BY-SA с атрибуция
Не связан с StackOverflow
scroll top