Почему JVM запускается медленно?

Question

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

Если подумать, как время запуска JVM сравнивается с CLR в Windows? Как насчет моно CLR?

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

Answer 1

Вот что говорит Википедия по этому вопросу (с некоторыми ссылками).

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

Answer 2

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

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

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

Чтобы узнать больше о функции, которую вы можете посетить: Класс обмена данными

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

Answer 3

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

Answer 4

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

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

• http://en.wikipedia.org/wiki/64-bit#32_vs_64_bit
• http://java.sun.com/docs/hotspot/HotSpotFAQ.html#64bit_compilers

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

Answer 5

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

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

Answer 6

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

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

Answer 7

Есть несколько причин:

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

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

Answer 8

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

Простой hello world, стилизованный под один класс liner с main, все еще требует много загрузки и инициализации. Проверка класса требует много проверки и валидации зависимостей, что требует времени и большого количества инструкций процессора. С другой стороны, программа на Си не выполнит ничего из этого, выполнит несколько инструкций и затем вызовет функцию принтера.