尝试设置 JVM 标志时 Java 运行时崩溃

Question

我在 docker 容器中有一个微服务（springboot）。我还传递了一长串 JVM 标志，以便程序在该 VM 环境中运行以测试每个标志组合的延迟值。

我正在使用此命令启动容器：

docker run --rm --name factorialorialContainer -p 8080:8080 -e JAVA_OPTIONS="$(cat /Users/sulekahelmini/Documents/fyp/fyp_work/MLscripts/flags.txt)" suleka96/factorial:latest

flags.txt 看起来像这样：

-XX:-ResizePLAB -XX:+ResizeOldPLAB -XX:+AlwaysPreTouch -XX:-ParallelRefProcEnabled -XX:-ParallelRefProcBalancingEnabled -XX:-UseTLAB -XX:-ResizeTLAB -XX:+ZeroTLAB -XX:+FastTLABRefill -XX:-UseAutoGCSelectPolicy -XX:-UseAdaptiveSizePolicy -XX:+UsePSAdaptiveSurvivorSizePolicy -XX:-UseAdaptiveGenerationSizePolicyAtMinorCollection -XX:+UseAdaptiveGenerationSizePolicyAtMajorCollection -XX:-UseAdaptiveSizePolicyWithSystemGC -XX:+UseAdaptiveGCBoundary -XX:+UseAdaptiveSizePolicy4BXX1BXXYouprintSizePolicy5PLA:1OXX3Go GCTaskTimeStampEntries=255 -XX:TargetPLABWastePct=5 -XX:PLABWeight=73 -XX:OldPLABWeight=21 -XX:MarkStackSize=5927008 -XX:MarkStackSizeMax=579749070 -XX:RefDiscoveryPolicy=1 -XX:InitiatingHeapSizeR 0 -XX:MaxRAMFraction=3 -XX:MinRAMFraction=3 -XX:InitialRAMFraction=74 -XX:AutoGCSelectPauseMillis=2934 -XX:AdaptiveSizeThroughPutPolicy=0 -XX:AdaptiveSizePausePolicy=0 -XX:AdaptiveSizePolicyInitializingSteps=24 -XX:AdaptiveSizePolicyOutputInterval=4060 -XX:AdaptiveSizePolicyWeight=11 -XX:AdaptiveTimeWeight=60motPadding=30 3 -XX:SurvivorPadding=1 -XX:ThresholdTolerance=11 -XX:AdaptiveSizePolicyCollectionCostMargin=68 -XX:YoungGenerationSizeIncrement=28 -XX:YoungGenerationSizeSupplement=81 -XX:YoungGenerationSizeSupplementDecay=9 -XX:TenuredGeneration48SupplementDecay=9-XX:TenuredGeneration48Supplement=GenerationSizeIncrement=68 -XX:YoungGenerationSizeIncrement=28 XX:TenuredGenerationSizeSupplementDecay=2 -XX:MaxGCPauseMillis=16157174462788231168 -XX:GCPauseIntervalMillis=3009 -XX:GCTimeRatio=77 -XX:AdaptiveSizeDecrementScaleFactor=4 -XX:AdaptiveSizeMajorSvivorRXX:TimeScaleMinatioSvivoRXX:BaseFootPrintEstimate=463170010 -XX:GCHeapFreeLimit=4 -XX:ProcessDistributionStride=4 -Xms338224019 -Xmx1103493303

当我运行上述 docker 命令时，出现以下错误：

#

Java 运行时环境检测到一个致命错误：

#

SIGSEGV (0xb) 在 pc=0x00007f9b014fe3c3，pid=1，tid=0x00007f9b10633b10

#

JRE 版本：OpenJDK 运行时环境 (8.0_212-b04) (build 1.8.0_212-b04)

Java VM：OpenJDK 64 位服务器 VM（25.212-b04 混合模式 linux-amd64 压缩 oops）

衍生：冰茶 3.12.0

分发：自定义构建（UTC 2019 年 5 月 4 日星期六 17:33:35）

有问题的框架：

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

#

无法写入核心转储。核心转储已被禁用。要启用核心转储，请在再次启动 Java 之前尝试“ulimit -c unlimited”

#

包含更多信息的错误报告文件保存为：

/usr/src/factorial/hs_err_pid1.log 编译方法 (c1) 1054 256 1 java.net.URL::getRef (5 bytes) 堆中的总数

[0x00007f9b0166bad0,0x00007f9b0166bd60] = 656重定位
[0x00007f9b0166bbf8,0x00007f9b0166bc20] = 40主代码
[0x00007f9b0166bc20,0x00007f9b0166bca0] = 128存根码
[0x00007f9b0166bca0,0x00007f9b0166bd30] = 144个范围数据
[0x00007f9b0166bd30,0x00007f9b0166bd38] = 8作用域个
[0x00007f9b0166bd38,0x00007f9b0166bd58] = 32 个依赖项
[0x00007f9b0166bd58,0x00007f9b0166bd60] = 8 #

如果您想提交错误报告，请包括

有关如何重现错误并访问的说明：

https://icedtea.classpath.org/bugzilla

#

我在这里做错了什么？

Answer 1

这-XX:+ZeroTLAB是坏掉的选项。只是不要使用这个标志。

我猜这里涉及一个随机选项生成器，用于性能调整。虽然这个想法本身很好，并且有已知的案例^1,2当使用贝叶斯优化的机器学习帮助找到更好的 JVM 选项值时，这里的关键点是在实验中只包含那些含义和含义你很理解的选项.

实验中还要注意每个选项的合理范围，以及连接选项之间的相互关系。

然而，上面的选项列表看起来完全是随机的，没有多大意义（也许，除了 JVM 测试）。毫不奇怪，这种配置可能会产生不可预测的结果，包括 JVM 崩溃。

¹ 使用贝叶斯优化自动调优 JVM
² 使用 Graal 和机器学习对 Twitter 服务进行性能调优