Giters

dacapobench / dacapobench

The DaCapo benchmark suite

Home Page:https://www.dacapobench.org/

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

tradebeans and tradesoap won't start using OpenJDK > 21

JonasNorlinder opened this issue · comments

commented

Problem description

It seems like tradebeans nor tradesoap won't go pass the message NOTE: Starting watchdog timer with timeout of 55 seconds. Adjust timeout with the -f command line option. if one is using a version of OpenJDK that is greater than 21. DaCap23.11-chopin is affected, and as-well commits before this release (according to some quick testing).

I suspect some version check of the JVM is broken, but I could not find exactly where this is done to submit a patch.

How to reproduce

I downloaded https://jdk.java.net/21/and https://jdk.java.net/22/ respectively:

  • jdk-21.0.2/bin/java -jar ~/dacapo-23.11-chopin.jar tradebeans will work
  • jdk-22/bin/java -jar ~/dacapo-23.11-chopin.jar tradebeans will not work

My system

Linux/Ubuntu. x86_64

commented

For Dacapo-9.12 one had to add --add-opens java.base/java.lang=ALL-UNNAMED to make it run with newer JDKs, but this does not seems to help with the newer version of DaCapo

commented

I can reproduce this

commented

This bug report seems to be about the version checking, not about the failure itself.

The version check can easily be fixed, and I will do so.

If you know anything about why it won't work with > 21, then I'll see if I can fix or work around that.

commented

I suspect it's internal to Wildfly (still unclear whether it's a version check or not). See the shutdown stacktrace.

jdk.Shutdown {
  startTime = 05:03:55.721
  reason = "Shutdown requested from Java"
  eventThread = "Controller Boot Thread" (javaThreadId = 69)
  stackTrace = [
    java.lang.Shutdown.beforeHalt()
    java.lang.Shutdown.exit(int) line: 166
    java.lang.Runtime.exit(int) line: 188
    java.lang.System.exit(int) line: 1925
    org.jboss.as.server.SystemExiter$DefaultExiter.exit(int) line: 117
    org.jboss.as.server.SystemExiter.logAndExit(SystemExiter$ExitLogger, int) line: 98
    org.jboss.as.server.ServerService.boot(BootContext) line: 446
    org.jboss.as.controller.AbstractControllerService$1.run() line: 473
    java.lang.Thread.runWith(Object, Runnable) line: 1583
    java.lang.Thread.run() line: 1570
  ]
}
commented

I'm trying to differentiate a problem with the upstream (Wildfly), and with the harness (DaCapo).

It's outside my scope to fix the upstream, but I can fix the harness so that it gracefully handles the issue.

When a new JDK is released, large complex workloads like these may break. It's not part of my remit to track and handle those, but I am interested in ensuring DaCapo gracefully deals with them when they do occur.

commented

Thank you for confirming. My hunch about version checking was based on the previous issues encountered with Cassandra that had a similar issue due to a library was using a hard coded version string check (#172), as I could not find any obvious breaking changes between 21 and 22. I agree that it is not your responsibility to handle and track issues with upstream that breaks the JVM.

commented

Thanks for reporting this. I've pushed the fix.