Java время выполнения cra sh при попытке установить флаги JVM

Question

У меня есть микросервис (springboot) внутри docker контейнера. Я также передаю длинный список флагов JVM, чтобы программа работала в этой среде виртуальных машин для проверки значений задержки для каждой комбинации флагов.

Я использую эту команду для запуска контейнера:

docker run --rm --name factorialorialContainer -p 8080: 8080 -e JAVA_OPTIONS = "$ (cat / Пользователи / sulekahelmini / Documents / fyp / fyp_work / MLscripts / flags.txt) "suleka96 / factorial: последний

Файл flags.txt выглядит следующим образом:

-XX : -ResizePLAB -XX: + ResizeOldPLAB -XX: + AlwaysPreTouch -XX: -ParallelRefProcEnabled -XX: -ParallelRefProcBalancingEnabled -XX: -UseTLAB -XX: -ResizeTLAB -XX : -UseAdaptiveSizePolicy -XX: + UsePSAdaptiveSurvivorSizePolicy -XX: -UseAdaptiveGenerationSizePolicyAtMinorCollection -XX: + UseAdaptiveGenerationSizePolicyAtMajorCollection -XX: -UseAdaptiveSizePolicyWithSystemG C -XX: + UseAdaptiveGCBoundary -XX: + UseAdaptiveSizePolicyFootprintGoal -XX: YoungPLABSize = 4354 -XX: OldPLABSize = 1141 -XX : GCTaskTimeStampEntries = 255 -XX: TargetPLABWastePct = 5 -XX: PLABWeight = 73 -XX: OldPLABWeight = 21 -XX: MarkStackSize = 5927008 -XX: MarkStackSizeM ax = 579749070 -XX: RefDiscoveryPolicy = 1 -XX: InitiatingHeapOccupancyPercent = 49 -XX: ErgoHeapSizeLimit = 0 -XX: MaxRAMFraction = 3 -XX: MinRAMFraction = 3 -XX: начальное RAMFraction = 74 -XXXXXXX 0 -XX: AdaptiveSizePausePolicy = 0 -XX: AdaptiveSizePolicyInitializingSteps = 24 -XX: AdaptiveSizePolicyOutputInterval = 4060 -XX: AdaptiveSizePolicyWeight = 11 -XX: AdaptiveTimeWeight = 69 -XX :XX: 1-Xiv :XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX: Русский XX: пороговое значение толерантности = 11 -XX: AdaptiveSizePolicyCollectionCostMargin = 68 -XX: YoungGenerationSizeIncrement = 28 -XX: YoungGenerationSizeSupplement = 81 -XX: YoungGenerationSizeSupplementDecay = 9 -XX: Теннисный шестигранник MaxGCPauseMillis = 16157174462788231168 -XX: GCPauseIntervalMillis = 3009 -XX: GCTimeRatio = 77 -XX: AdaptiveSizeDecrementScaleFactor = 4 -XX: AdaptiveSizeMajorGCDecayTimeScale = 9 -XX: Minivatim = 4 -XX: BaseFootPrintEstimate = 463170010 -XX: GCHeapFreeLimit = 4 -XX: ProcessDistributionStride = 4 -Xms338224019 -Xmx1103493303

, когда я запускаю вышеупомянутую команду docker, я получаю ошибку ниже:

#

Среда выполнения Java обнаружила фатальную ошибку:

#

SIGSEGV (0xb) на ПК = 0x00007f9b014fe3c3, pid = 1, tid = 0x00007f9b10633b10

#

Версия JRE: среда выполнения OpenJDK (8.0_212-b04) (сборка 1.8.0_212-b04)

Java ВМ: 64-разрядная серверная виртуальная машина OpenJDK (смешанный режим 25.212-b04 * сжатые операции 1077 * -amd64)

Производная: IcedTea 3.12.0

Распространение: Пользовательская сборка (сб. 4 мая 17 : 33: 35 UT C 2019)

Проблемные c кадр:

j java. net .URLStreamHandler.toExternalForm (Ljava / net / URL;) Ljava / lang / String; + 88

#

Не удалось записать дамп памяти. Основные дампы были отключены. Чтобы включить дамп ядра, попробуйте «ulimit - c unlimited» перед повторным запуском Java

#

Файл отчета об ошибке с дополнительной информацией сохраняется как:

/usr/src/factorial/hs_err_pid1.log Скомпилированный метод (c1) 1054 256 1 java. net .URL :: getRef (5 байт) всего в куче

[0x00007f9b0166bad0,0x00007f9b0166bd60] = 656 переезд
[0x00007f9b0166bbf8,0x00007f9b0166bc20] = 40 основной код
[0x00007f9b0166bc20,0x00007f9b0166bca0] = 128 заглушки код
[0x00007f9b0166bca0,0x00007f9b0166bd30] = 144 * данные оптические прицелы 1053 * [0x00007f9b0166bd30,0x00007f9b0166bd38] = 8 шт * оптические прицелы 1054 * [0x00007f9b0166bd38,0x00007f9b0166bd58] = 32 зависимости
[0x00007f9b0166bd58,0x00007f9b0166bd60] = 8 #

Если вы хотите отправить отчет об ошибке, пожалуйста, включите

инструкции о том, как воспроизвести ошибку и посетите:

https://icedtea.classpath.org/bugzilla

#

Что я здесь не так делаю?

Answer 1

Это -XX:+ZeroTLAB опция, которая не работает. Только не используйте этот флаг.

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

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

Однако приведенный выше список параметров выглядит совершенно случайным и не имеет особого смысла (возможно, за исключением тестирования JVM). Не удивительно, что такая конфигурация может привести к непредсказуемым результатам, включая JVM cra sh.

---

¹ Автоматическая настройка JVM с байесовской оптимизацией
² Настройка производительности сервисов Twitter с помощью Graal и машинного обучения