Почему JVM работает медленно?

Что именно заставляет JVM (в частности, реализацию Sun) работать медленнее, чем другие среды выполнения, такие как CPython? Мое впечатление было то, что в основном это связано с загрузкой загружаемых библиотек независимо от того, нужны они или нет, но это похоже на то, что не должно занять 10 лет.

Подумайте об этом, как время начала JVM сравнивается с CLR в Windows? Как насчет Mono CLR?

ОБНОВЛЕНИЕ: меня особенно интересует случай использования небольших утилит, соединенных вместе, как это принято в Unix. Является ли Java подходящим для этого стиля? Независимо от того, что запускает Java на начальном этапе, она суммируется для каждого процесса Java или накладные расходы действительно проявляются только для первого процесса?

Ответ 1

Вот то, что Wikipedia должно сказать по этому вопросу (с некоторыми ссылками).

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

Ответ 2

Просто отметим некоторые решения:

Существует два механизма, которые позволяют ускорить запуск JVM. Первый, это механизм обмена данными класса, который поддерживается с момента обновления Java 6 Update 21 (только с VM клиента HotSpot и только с серийным сборщиком мусора, насколько я знаю)

Чтобы активировать его, вам нужно установить -Xshare (в некоторых вариантах реализации: -Xshareclasses).

Подробнее о функции, которую вы можете посетить: Передача данных классов

Второй механизм - это Java Quick Starter. Это позволяет предварительно загружать классы во время запуска ОС, см. Java Quick Starter для более подробной информации.

Ответ 3

Запуск тривиального Java-приложения с JVM-клиентом 1.6 (Java 6) кажется мгновенным на моей машине. Sun попыталась настроить клиентскую JVM для более быстрого запуска (и JVM клиента по умолчанию), поэтому, если вам не нужно много дополнительных файлов jar, запуск должен быть быстрым.

Ответ 4

Если вы используете Sun HotSpot для x86_64 (скомпилировано 64 бит), обратите внимание на то, что текущая реализация работает только в режиме сервера, то есть она предварительно компилирует каждый класс, который загружается с полной оптимизацией, тогда как 32-разрядная версия также поддерживает режим клиента, который как правило, откладывает оптимизацию и оптимизирует только часть процессора, но имеет более быстрое время запуска.

См. например:

При этом, по крайней мере, на моей машине (Linux x86_64 с 64-битным ядром), 32-битная версия HotSpot поддерживает как клиентский, так и серверный режим (через флаги -client и -server), но по умолчанию используется режим сервера, а 64-битный версия поддерживает только режим сервера.

Ответ 5

Это действительно зависит от того, что вы делаете во время запуска. Если вы запускаете приложение Hello World, оно занимает 0.15 секунд на моей машине.

Однако Java лучше подходит для работы в качестве клиента или сервера/службы, что означает, что время запуска не так важно, как время соединения (около 0,025 мс) или время отклика времени в оба конца (< 0,001 мс).

Ответ 6

Существует несколько причин:

много jar для загрузки
проверка (убедитесь, что код не делает злые вещи)
JIT (только во время компиляции) накладные расходы

Я не уверен в CLR, но я думаю, что это происходит быстрее, потому что он кэширует собственную версию сборок в следующий раз (так что это не нужно JIT). CPython запускается быстрее, потому что это интерпретатор, а IIRC, не делает JIT.

Ответ 7

В дополнение к уже упомянутым словам (классы загрузки, например, из сжатых JAR); работа в интерпретируемом режиме до того, как HotSpot компилирует часто используемый байт-код; и компиляции HotSpot, также существует довольно много одноразовых инициализаций, выполняемых самими классами JDK. Многие оптимизации выполняются в пользу более длительных систем, где скорость запуска меньше беспокоит.

А что касается коннеклинга стиля unix: вы, конечно, НЕ хотите запускать и перезапускать JVM несколько раз. Это не будет эффективным. Скорее всего, цепочка инструментов должна происходить в JVM. Это не может быть легко смешано с инструментами, отличными от Java Unix, за исключением запуска таких инструментов из JVM.

Ответ 8

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

Простой класс приветствия, созданный в стиле одного класса линейки с основным, требует многого для загрузки и инициализации. Для проверки класса требуется много проверки и проверки зависимостей, которые будут стоить время и многие инструкции ЦП. С другой стороны, программа C не будет выполнять какие-либо из них и будет содержать несколько инструкций, а затем вызвать функцию принтера.