Сохраняет ли Java оптимизацию времени выполнения?

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

То, что вы видите, почти наверняка связано с кешированием диска.

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

Хорошо, я нашел, где это читал. Это все из "Learning Java" (O'Reilly 2005):

The problem with a traditional JIT compilation is that optimizing code takes time. So a JIT compiler can produce decent results but may suffer a significant latency when the application starts up. This is generally not a problem for long-running server-side applications but is a serious problem for client-side software and applications run on smaller devices with limited capabilities. To address this, Sun's compiler technology, called HotSpot, uses a trick called adaptive compilation. If you look at what programs actually spend their time doing, it turns out that they spend almost all their time executing a relatively small part of the code again and again. The chunk of code that is executed repeatedly may be only a small fraction of the total program, but its behavior determines the program's overall performance. Adaptive compilation also allows the Java runtime to take advantage of new kinds of optimizations that simply can't be done in a statically compiled language, hence the claim that Java code can run faster than C/C++ in some cases.

To take advantage of this fact, HotSpot starts out as a normal Java bytecode interpreter, but with a difference: it measures (profiles) the code as it is executing to see what parts are being executed repeatedly. Once it knows which parts of the code are crucial to performance, HotSpot compiles those sections into optimal native machine code. Since it compiles only a small portion of the program into machine code, it can afford to take the time necessary to optimize those portions. The rest of the program may not need to be compiled at all—just interpreted—saving memory and time. In fact, Sun's default Java VM can run in one of two modes: client and server, which tell it whether to emphasize quick startup time and memory conservation or flat out performance.

A natural question to ask at this point is, Why throw away all this good profiling information each time an application shuts down? Well, Sun has partially broached this topic with the release of Java 5.0 through the use of shared, read-only classes that are stored persistently in an optimized form. This significantly reduces both the startup time and overhead of running many Java applications on a given machine. The technology for doing this is complex, but the idea is simple: optimize the parts of the program that need to go fast, and don't worry about the rest.

Мне как бы интересно, как далеко зашла Sun с Java 5.0.

Я согласен, что это, скорее всего, результат кеширования диска.

К вашему сведению, виртуальная машина IBM Java 6 действительно содержит опережающий компилятор (AOT). Код не так оптимизирован, как то, что создаст JIT, но он хранится на виртуальных машинах, я верю в своего рода постоянную общую память. Его основное преимущество - повышение производительности при запуске. Виртуальная машина IBM по умолчанию JIT выполняет метод после того, как он был вызван 1000 раз. Если он знает, что метод будет вызываться 1000 раз только во время запуска виртуальной машины (подумайте о широко используемом методе, таком как java.lang.String.equals(...)), тогда ему выгодно сохранить его в кеше AOT, чтобы ему никогда не приходилось тратить время на компиляцию. во время выполнения.

Я согласен с тем, что разница в производительности, увиденная на плакате, скорее всего, вызвана задержкой диска при переносе JRE в память. Компилятор Just In Time (JIT) не повлияет на производительность небольшого приложения.

Java 1.6u10 (http://download.java.net/jdk6/) касается JAR среды выполнения в фоновом процессе (даже если Java не запущена), чтобы сохранить данные в дисковом кэше. Это значительно сокращает время запуска (что является огромным преимуществом для настольных приложений, но, вероятно, имеет незначительную ценность для приложений на стороне сервера).

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

Предварительная компиляция классов среды выполнения действительно немного помогает настольным приложениям (как и вышеупомянутая предварительная загрузка дискового кеша 6u10).

Вы должны описать, как проводился тест. Особенно в этот момент вы начинаете отсчитывать время.

Если вы включите время запуска JVM (что полезно для тестирования взаимодействия с пользователем, но не так полезно для оптимизации кода Java), то это может быть эффект кэширования файловой системы или он может быть вызван функцией, называемой «Совместное использование данных класса Java»:

Для Солнца:

http://java.sun.com/j2se/1.5.0/docs/guide/vm/class-data-sharing.html

Это вариант, при котором JVM сохраняет подготовленный образ классов среды выполнения в файл, чтобы обеспечить более быструю загрузку (и совместное использование) этих классов при следующем запуске. Вы можете управлять этим с помощью -Xshare: on или -Xshare: off с помощью Sun JVM. По умолчанию используется -Xshare: auto, который будет загружать образ общих классов, если он присутствует, а если он отсутствует, он запишет его при первом запуске, если каталог доступен для записи.

С IBM Java 5 это, кстати, еще более мощно:

http://www.ibm.com/developerworks/java/library/j-ibmjava4/

Я не знаю ни одной распространенной JVM, которая сохраняет статистику JIT.