JVM дизайнерское решение

Question

Почему jvm требует около 10 МБ памяти для простого привет-мира, а clr - нет. Каков здесь компромисс, то есть, что выигрывает jvm, делая это?

Позвольте мне немного уточнить, потому что я не передаю вопрос, который у меня в голове. Между средами выполнения jvm и clr явно есть архитектурное различие. У jvm значительно больше памяти, чем у clr. Я предполагаю, что есть какая-то польза для этих накладных расходов, иначе зачем они существуют. Я спрашиваю, каковы компромиссы в этих двух проектах. Какую выгоду выигрывает jvm от накладных расходов памяти?

Answer 1

Я полагаю, одна из причин в том, что Java должна делать все сама (еще один аспект независимости платформы). Например, Swing рисует свои собственные компоненты с нуля, он не полагается на ОС для их рисования. Это все должно произойти в памяти. Windows может многое сделать, но linux не должен (или делает по-другому) полностью содержаться в Java, чтобы он работал одинаково на обоих.

Java также всегда настаивает на том, что вся ее библиотека «связана» и доступна. Поскольку он не использует библиотеки DLL (они не будут доступны на каждой платформе), все должно быть загружено и отслежено Java.

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

Так что, если вы думаете обо всем, что C # может делегировать ОС, с которой он связан, и обо всем, что Java должна делать для ОС, чтобы компенсировать другим, следует ожидать разницы.

Я запускаю Java-приложения на 2 встроенных платформах. Один был анализатором спектра, где он фактически рисовал следы, а другой - кабельные приставки.

В обоих случаях этот минимальный объем памяти не был проблемой - были проблемы, специфичные для Java, которых просто не было. Количество созданных объектов и скорость рисования Swing были большими проблемами в этих случаях.

Answer 2

Я не знаю, важен ли начальный объем памяти или размер приложения Hello World. Разница может быть связана с количеством и размерами библиотек, загружаемых JVM / CLR. Также может быть объем памяти, который предварительно выделен для пулов сбора мусора.

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

http://benpryor.com/blog/2006/05/04/jvm-vs-clr-memory-allocation/

Пример управления памятью (JVM & CLR)

Пример управления памятью находится в Power Point. Очень интересная презентация.

Answer 3

Похоже, что Java просто использует больше виртуальной памяти.

USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
amwise   20598  0.0  0.5  22052  5624 pts/3    Sl+  14:59   0:00 mono Test.exe
amwise   20601  0.0  0.7 214312  7284 pts/2    Sl+  15:00   0:00 java Program

Я создал тестовую программу на C # и на Java, которая печатает строку «test» и ждет ввода. Я считаю, что значение размера резидентного набора (RSS) более точно показывает использование памяти. Использование виртуальной памяти (VSZ) является менее значимым.

Насколько я понимаю, приложения могут резервировать тонну виртуальной памяти, фактически не используя реальную память. Например, вы можете попросить функцию VirtualAlloc в Windows зарезервировать или зафиксировать виртуальную память.

EDIT:

Вот симпатичная картинка из моего окна: альтернативный текст http://awise.us/images/mem.png

Каждое приложение представляло собой простой printf с последующим getchar. Много использования виртуальной памяти Java и CLR. Версия C практически ни от чего не зависит, поэтому ее использование памяти относительно мало.

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

EDIT:

Этот инструмент VMMap от Microsoft может быть полезен для выяснения, куда идет память.

Answer 4

JVM загружает множество ненужных базовых классов при каждом запуске из rt.jar. К сожалению, внутренние перекрестные зависимости (java.lang <-> java.io) java-пакетов затрудняют частичную инициализацию во время выполнения. Не говоря уже о том, что сам файл rt.jar занимает более 40 МБ, требует много времени для поиска и распаковки.

Пост Java 6u10, кажется, загружает вещи немного умнее (в нем есть служба быстрого старта jqs.exe = java для хранения необходимых данных в памяти и более быстрого запуска), однако Java 7 считается лучше

Обозреватель процессов в Windows правильно сообщает о приватных байтах (приватные байты - это те области памяти, которые не используются ни одной dll).

Немного больше раздражает то, что через 10 лет JVM по-прежнему использует 64 МБ памяти. Действительно раздражает использование -Xmx почти каждый раз, и он не может запускать требовательные программы в банках простым двойным щелчком (если я не изменяю команду назначения расширения файла).

Answer 5

JVM считает все общие библиотеки, используют ли они память или нет.

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

Answer 6

CLR считается частью ОС, поэтому диспетчер задач не сообщает о потреблении памяти в процессе приложения.