Crash on OpenJ9 JVM
See original GitHub issueWhen Finagle is used with the OpenJ9 JVM, it crashes with a java.lang.UnsatisfiedLinkError
.
Expected behavior
When running on a non-Hotspot JVM, I would expect JVM stats to be unavailable, but things should otherwise work normally.
Actual behavior
When starting a Finagle application on OpenJ9, I get this stack trace:
java.lang.UnsatisfiedLinkError: sun/management/VMManagementImpl.getVersion0()Ljava/lang/String;
at sun.management.VMManagementImpl.<clinit>(VMManagementImpl.java:64)
at sun.management.ManagementFactoryHelper.<clinit>(ManagementFactoryHelper.java:455)
at java.lang.Class.forNameImpl(Native Method)
at java.lang.Class.forName(Class.java:297)
at com.twitter.jvm.Hotspot.liftedTree1$1(Hotspot.scala:37)
at com.twitter.jvm.Hotspot.<init>(Hotspot.scala:31)
at com.twitter.jvm.Jvm$.liftedTree2$1(Jvm.scala:262)
at com.twitter.jvm.Jvm$._jvm$lzycompute(Jvm.scala:262)
at com.twitter.jvm.Jvm$._jvm(Jvm.scala:261)
at com.twitter.jvm.Jvm$.apply(Jvm.scala:274)
at com.twitter.jvm.JvmStats$.register(JvmStats.scala:98)
at com.twitter.finagle.Init$.<init>(Init.scala:46)
at com.twitter.finagle.Init$.<clinit>(Init.scala)
at com.twitter.finagle.client.StackClient$.endpointStack(StackClient.scala:58)
at com.twitter.finagle.client.StackClient$.newStack(StackClient.scala:224)
at com.twitter.finagle.buoyant.H2$Client$.<init>(H2.scala:28)
at com.twitter.finagle.buoyant.H2$Client$.<clinit>(H2.scala)
at io.buoyant.router.H2$Router$.<init>(H2.scala:49)
at io.buoyant.router.H2$Router$.<clinit>(H2.scala)
at io.buoyant.router.H2$.<init>(H2.scala:77)
at io.buoyant.router.H2$.<clinit>(H2.scala)
at io.buoyant.linkerd.protocol.H2Initializer.<init>(H2Config.scala:40)
at java.lang.J9VMInternals.newInstanceImpl(Native Method)
at java.lang.Class.newInstance(Class.java:1773)
at com.twitter.app.LoadService$.$anonfun$apply$7(LoadService.scala:73)
at com.twitter.app.LoadService$$$Lambda$81.00000000CC7244F0.apply(Unknown Source)
at scala.collection.TraversableLike.$anonfun$flatMap$1(TraversableLike.scala:241)
at scala.collection.TraversableLike$$Lambda$24.00000000CC587E30.apply(Unknown Source)
at scala.collection.mutable.ResizableArray.foreach(ResizableArray.scala:59)
at scala.collection.mutable.ResizableArray.foreach$(ResizableArray.scala:52)
at scala.collection.mutable.ArrayBuffer.foreach(ArrayBuffer.scala:48)
at scala.collection.TraversableLike.flatMap(TraversableLike.scala:241)
at scala.collection.TraversableLike.flatMap$(TraversableLike.scala:238)
at scala.collection.AbstractTraversable.flatMap(Traversable.scala:104)
at com.twitter.app.LoadService$.apply(LoadService.scala:62)
at com.twitter.finagle.util.LoadService$.apply(LoadService.scala:14)
at io.buoyant.linkerd.Linker$.LoadedInitializers$lzycompute(Linker.scala:65)
at io.buoyant.linkerd.Linker$.LoadedInitializers(Linker.scala:64)
at io.buoyant.linkerd.Linker$.parse$default$2(Linker.scala:79)
at io.buoyant.linkerd.Main$.loadLinker(Main.scala:69)
at io.buoyant.linkerd.Main$.main(Main.scala:36)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at com.twitter.app.App.$anonfun$nonExitingMain$3(App.scala:233)
at com.twitter.app.App$$Lambda$178.00000000CCBD6FA0.apply(Unknown Source)
at scala.Option.foreach(Option.scala:257)
at com.twitter.app.App.nonExitingMain(App.scala:232)
at com.twitter.app.App.nonExitingMain$(App.scala:210)
at io.buoyant.linkerd.Main$.nonExitingMain(Main.scala:20)
at com.twitter.app.App.main(App.scala:198)
at com.twitter.app.App.main$(App.scala:196)
at io.buoyant.linkerd.Main$.main(Main.scala:20)
at io.buoyant.linkerd.Main.main(Main.scala)
Exception thrown in main on startup
I believe that the offending code is in Jvm.scala:
private lazy val _jvm =
try new Hotspot
catch {
case NonFatal(_) => NilJvm
}
Attempting to create a Hotspot results in a java.lang.UnsatisfiedLinkError which I believe is not NonFatal.
Steps to reproduce the behavior
- Finagle and Twitter-util version 7.1.0
- Build an application using Finagle
- Build a docker image for that app using
adoptopenjdk/openjdk8-openj9:jdk8u162-b12_openj9-0.8.0
as the base - Run the application inside the container
Java version inside the conatiner:
openjdk version "1.8.0_162"
OpenJDK Runtime Environment (build 1.8.0_162-b12)
Eclipse OpenJ9 VM (build openj9-0.8.0, JRE 1.8.0 Linux amd64-64 Compressed References 20180315_120 (JIT enabled, AOT enabled)
OpenJ9 - e24e8aa9
OMR - 3e8296b4
JCL - ee1e77df1d based on jdk8u162-b12)
Please list all relevant steps to reproduce the observed behavior.
Issue Analytics
- State:
- Created 5 years ago
- Comments:5 (5 by maintainers)
Top Results From Across the Web
OpenJ9 JVM crash when loading native library in Linux #13269
We have been seeing a JVM crash when loading native code using System.loadLibrary in Linux . This crash is only visible on OpenJDK11...
Read more >IJ31889: CRASH DURING JIT COMPILATION - IBM
Error Message: In the cases observed so far the problem has caused the JVM to crash in TR_ExceptionCheckMotion::perform() called from ...
Read more >[1.1.4] API: Crash when running under OpenJ9 JVM on Windows
SikuliX API crashes on Windows when running under OpenJ9 JVM (formerly IBM J9). The crash happens when the JVM loads the Finder class....
Read more >Sync fails silently when Java process critically crashes
To simulate a Java process crash, download for example OpenJ9 JDK for linux ... are on macOS and set it as a Gradle...
Read more >Newest 'openj9' Questions - Stack Overflow
We hosted a java application in websphere 9 / jre 1.8. Intermittently JVM crash and generating the javacore. We are getting below error...
Read more >Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start FreeTop Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
Top GitHub Comments
Yes! 🎉
Is this resolved by #218?