В чем разница между внутренней работой Java JVM и .NET CLR?

Question

В чем разница между внутренней работой Java JVM и CLR .NET?

Возможно, отправной точкой будет то, являются ли они в основном одинаковыми в своих соответствующих средах (Java> JVM> Машинный код) (C #> CLR> IL).

---

Обновление: Несколько человек ссылались на моменты, которые я пытался охватить:

1. Сборка мусора
2. Бокс / распаковка
3. JIT-отладка
4. Дженерики / Templates
5. Пожалуйста, не стесняйтесь предлагать другие хорошие темы, которые отличают их.

@ Джордж Мауэр - это звучит очень интересно:

Уже опубликовал это один раз, но вот серия интервью с главным языковым дизайнером c # Андерсом Хейлсбергом.

Answer 1

Это должна быть отличная тема.

Одно из самых больших различий между CLR и JVM - это встроенная в дженерики CLR.

Вместо этого Java удаляет универсальные типы, а JVM может работать только с объектами, автоматически блокируя объекты, которые кажутся псевдообобщенными.

Answer 2

С здесь . Я не мог бы сказать это лучше (Ну, за исключением войны пламенем, это беспламенное место :-)).

Здравствуйте,

Отвечая на ваш вопрос кажется чревато опасностью, вызвав пламя войну, поэтому я буду действовать осторожно.

Есть ряд фундаментальных технические сходства между Java Runtime и общий язык Время выполнения, включая сборку мусора память, промежуточный язык (Microsoft IL против Java ByteCode), основные системные библиотеки и поддержка языки довольно высокого уровня, код безопасность и развертывание.

Однако каждая из этих «похожих» областей также есть ряд значительных и небольшие различия, и это за простое сообщение форума на опишите большинство из них.

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

Answer 3

У CLR и JVM есть цели и принципы, которые отличаются больше, чем вы думаете. В целом, JVM направлена ​​на оптимизацию более динамического высокоуровневого кода, в то время как CLR предоставляет вам более низкоуровневые инструменты для выполнения этих видов оптимизации самостоятельно.

Хорошим примером является распределение стека. В CLR у вас есть явное распределение в стеке пользовательских типов значений. В JVM единственные пользовательские типы являются ссылочными типами, но JVM может преобразовывать выделения кучи в распределения стека при определенных обстоятельствах с помощью Escape-анализа.

Еще один пример. В Java методы являются виртуальными по умолчанию. На C # по крайней мере их нет. Гораздо сложнее оптимизировать вызовы виртуальных методов, поскольку код, который выполняется на данном сайте вызовов, не может быть определен статически.

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

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

Большой процент кода Jotsp Hotspot посвящен этим адаптивным оптимизациям, и именно они ставят Java в тот же уровень производительности, что и собственный код, для большинства вычислений общего назначения в начале 2000-х годов. Они также делают JVM достойной целью для динамических языков. Здесь я исключаю более недавние разработки динамических языков исполнения и invokedynamic, поскольку я недостаточно знаю о DLR.

Answer 4

Одно существенное отличие состоит в том, что JVM переносима на разные платформы и работает на Linux, Macintosh и многих мобильных телефонах и встроенных устройствах.

CLR работает на платформах, поддерживаемых Microsoft, с проектом Mono, обеспечивающим частичную поддержку более старых версий CLR и еще несколько.

Внутренне это означает, что производительность JVM будет варьироваться на этих разных платформах в зависимости от возможностей, предоставляемых самими платформами.

Answer 5

Мигель де Икаса упоминает здесь :

Опытные программисты заметят, что очень похоже на Java и Java VM. Они правы, выше это как Java.

CIL имеет одну особенность, не найденную в Java: представление байт-кода, которое является достаточно мощным, чтобы использоваться в качестве целевой для многих языков: от C ++, C, Fortran и Eiffel до Lisp и Haskell, включая такие вещи, как Java, C #, JavaScript и Visual Basic в смеси.

Хотелось бы, чтобы у меня было время остановиться более подробно, но ради этого аргумента, выше будет достаточно.

Тем не менее, комментарии касаются некоторых деталей, таких как оптимизация хвостовых вызовов. Однако с 2002 года партия изменилась - и CLR, и JVM теперь используют несколько языков для таргетинга. Но, тем не менее, стоит прочитать.

Answer 6

Есть и различия в сборке мусора. JVM использует Копирующий коллектор и Марка и развертки. Пользователь .NET Копирование коллектора и маркировка и компактность (гораздо сложнее реализовать).

Также важно стирание типа, упомянутое Flyswat. JVM не имеет ни малейшего представления о дженериках, и все это объект и связанные перфекты. штраф за бокс и распаковку. Также рефлексия не даст вам общей информации. CLR изначально поддерживает дженерики.

Answer 7

Насколько я знаю, .Net CLR по-прежнему обладает гораздо более гибкой и мощной защитой кода доступа, встроенной в среду выполнения, позволяющей гораздо более детализированные разрешения и политику выполнения.

Answer 8

Как сказал Винко, полная информация выходит за рамки поста на форуме. Различия / сходства сводятся к этому:

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

Внутренняя часть того, как эти среды выполнения на самом деле реализованы, большей частью являются собственностью Microsoft и Sun. Например, алгоритмы, используемые системами сбора мусора, хотя, вероятно, и схожи по технической функциональности, отличаются по реализации.