Внутри Java 9 — схема версий, многоадресные JAR и многое другое

 java9 -cp out-mr/mr.jar -Xlog:os,modules*,gc* ...Main [0.002s][info][os] SafePoint Polling address: 0x00007f9c7f307000 [0.002s][info][os] Memory Serialize Page address: 0x00007f9c7f305000 [0.003s][info][os] HotSpot is running with glibc 2.22, NPTL 2.22 [0.007s][info][gc,heap] Heap region size: 1M [0.009s][info][gc ] Using G1 [0.009s][info][gc,heap,coops] Heap address: 0x00000006c6200000, size: 3998 MB, Compressed Oops mode: Zero based, Oop shift amount: 3 [0.077s][info][modules,startuptime] Phase2 initialization, 0.0367418 secs Java 9 version [0.090s][info][gc,heap,exit ] Heap [0.090s][info][gc,heap,exit ] garbage-first heap total 256000K, used 2048K [0x00000006c6200000, 0x00000006c63007d0, 0x00000007c0000000) [0.090s][info][gc,heap,exit ] region size 1024K, 3 young (3072K), 0 survivors (0K) [0.090s][info][gc,heap,exit ] Metaspace used 4225K, capacity 4532K, committed 4864K, reserved 1056768K [0.090s][info][gc,heap,exit ] class space used 414K, capacity 428K, committed 512K, reserved 1048576K 

Послушайте, даже сборщику мусора было что сказать — в данном случае относительно выхода и кучи.

Это была только поверхность — есть еще много вариантов настройки. JEP довольно хорошо объясняет все это, включая примеры.

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

Проверка флага командной строки

Вот забавный факт: виртуальная машина Java 8 не проверяет значения, заданные для флагов командной строки, пока они на самом деле не нужны. К сожалению, это может быть довольно поздно в жизненном цикле приложения, и я вижу, как последующие сбои могут привести к разочарованию. Давайте возьмем этот пример:

 java -cp out-mr/mr.jar -XX:BlockLayoutMinDiamondPercentage=120 ...Main 

Хотя я понятия не имею, что делает BlockLayoutMinDiamondPercentage (и ему было лень его искать), на самом деле не похоже, что 120 — это действительный процент. Java 8 не потревожена этим и успешно выполняет наш JAR, выполняя весь код успешно — очевидно, значение не требуется при выполнении этой программы. Или, может быть, 120 является действительным значением в конце концов? Java 9 так не считает:

 java9 -cp out-mr/mr.jar -XX:BlockLayoutMinDiamondPercentage=120 ...Main intx BlockLayoutMinDiamondPercentage=120 is outside the allowed range [ 0 ... 100 ] Improperly specified VM option 'BlockLayoutMinDiamondPercentage=120' Error: Could not create the Java Virtual Machine. Error: A fatal exception has occurred. Program will exit. 

Лучше … Потому что благодаря JEP 245 Java 9 имеет возможность проверять все входные флаги во время запуска. И, как видно выше, он также печатает пояснительные сообщения об ошибках.

Зарезервированные области стека

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

Возьмем, к примеру, ReentrantLock , где ошибка StackOverflowError в неподходящий момент может повредить состояние блокировки, чтобы ее никогда больше не разблокировать. Если приложение решает перехватить ошибки и продолжить работу, блокировка блокирует все вовлеченные потоки. Не совсем отлично.

Резервирование кадров для критических разделов

JEP 270 добавил новую аннотацию @ReservedStackAccess . С его помощью методы могут идентифицировать себя как критические разделы, которые необходимо завершить, если система не должна оказаться в поврежденном состоянии. Поведение JVM в отношении стека выполнения было соответствующим образом изменено. Он резервирует некоторое дополнительное пространство стека и всякий раз, когда возникает @ReservedStackAccess StackOverflowError он проверяет, есть ли в стеке метод @ReservedStackAccess аннотированный. Если это так, это пространство становится доступным для него, чтобы он мог выполнять дополнительную работу. Как только это сделано, исключение тем не менее выдается.

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

Сколько места зарезервировано в стеке? На данный момент по умолчанию используется одна страница памяти, и «эксперименты показали, что этого достаточно для покрытия критических разделов блокировок java.util.concurrent , которые были аннотированы до сих пор».

пример

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

 int depth; @ReservedStackAccess private void determineDepthWithReservedStack() { determineDepth(); } private void determineDepth() { depth = 0; try { recurseToDetermineMaxDepth(); } catch (StackOverflowError err) { } System.out.printf("Depth: %d%n", depth); } private void recurseToDetermineMaxDepth() { depth++; recurseToDetermineMaxDepth(); } 

Идя снизу вверх, вы видите метод, бесконечно рекурсивный и увеличивающий поле depth , другой метод, обертывающий его, перехватывающий исключение и печатающий полученную глубину, и, наконец, третий метод, запрашивающий доступ к зарезервированной области стека. Я не пользуюсь зарезервированной областью стека, поскольку я просто исчерпываю ее с помощью более рекурсивных вызовов. Это означает, что вызовы defineDepth или determineDepthWithReservedStack конечном итоге приведет к переполнению стека, что приведет к печати количества вызовов. Но вывод должен отличаться и в самом деле:

 DEPTH USING REGULAR STACK Depth: 21392 DEPTH USING RESERVED STACK Java HotSpot(TM) 64-Bit Server VM warning: Potentially dangerous stack overflow in ReservedStackAccess annotated method org.codefx.demo.java9.internal.stack.ReservingStackAreas.determineDepthWithReservedStack()V [1] Depth: 59544 

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

Внутренность!

В случае, если вы устали, имейте в виду, что это внутренний API. Чтобы убедить компилятор предоставить вам доступ к аннотации, вам нужно взломать базовый модуль с помощью --add-exports java.base/jdk.internal.vm.annotation=<module> , где <module> — это либо модуль вашего модуля. имя (если вы уже делаете это) или ALL-UNNAMED . Но JVM все равно будет игнорировать аннотацию, если вы не отключите ограничение для привилегированного кода с помощью -XX:-RestrictReservedStack .

Посмотрите, как это происходит вместе в compile.sh и run.sh в демонстрационном проекте .

Но подождите, еще больше!

Да, есть еще кое-что, и на этот раз вам не придется ждать два месяца — обещаю. Вторая часть должна быть сделана на следующей неделе и будет посвящена повышению производительности и улучшению компилятора. Я уверен, что в новостной рассылке будет краткий обзор, так что если вам интересно подписаться (до вечера пятницы по UTC) или подписаться на нас в Medium, либо я, либо SitePoint (или оба), где он появится на следующей неделе.

Если вам понравилась эта статья, помогите нам распространить информацию и расскажите об этом другу или коллеге!