JDK-8227645 : Some tests in serviceability/sa run with fixed -Xmx values and risk running out of memory
  • Type: Bug
  • Component: hotspot
  • Sub-Component: svc-agent
  • Affected Version: 11.0.5-oracle,13,14
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2019-07-12
  • Updated: 2020-06-01
  • Resolved: 2019-08-09
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 11 JDK 13 JDK 14
11.0.7-oracleFixed 13.0.4Fixed 14 b10Fixed
Description
Both of these tests run with -Xmx8g:

TestHeapDumpForLargeArray.java and
ClhsdbRegionDetailsScanOopsForG1.java

The make files calculates a MaxRAMPercentage based on the calculated test concurrency. When running these tests with concurrency, we risk running out of memory, the suggested solution is to make sure at least these tests don't run concurrently by using the exclusiveAccess feature in JTreg.
Comments
Fix request (13u) I would like to downport this to 13u Applies cleanly.
19-05-2020
Fix request (11u) I would like to downport this for parity with 11.0.7-oracle. Files are moved. I had to resolve one file: http://mail.openjdk.java.net/pipermail/jdk-updates-dev/2020-January/002332.html
03-01-2020
This needs to be backported to 11u as we see the same test failure issues there.
04-09-2019
URL: https://hg.openjdk.java.net/jdk/jdk/rev/a64caa5269cf User: cjplummer Date: 2019-08-09 18:28:39 +0000
09-08-2019
If no one objects, I'm just going to move these two tests to: open/test/jtreg/resourcehogs/serviceability/sa Please let me know if you prefer a different name. Also, how do you want to handle triggering the running of these tests. I can't just add this directory to :hotspot_serviceability. I think that will result in them still running concurrent with the other serviceability tests.
23-07-2019
Is there a reason this has only recently become an issue? It seems various SA tests are failing due to this the past month on windows-x64
19-07-2019
I think moving the resource hogs to their own directory and using exclusiveAccess.dirs on that directory is a good step forward, it probably won't solve all the issues but it should make them less likely.
12-07-2019
Yesterday I noticed multiple test failures in serviceability/sa that seemed OOM related when I ran on my 4 core desktop with JOBS=8 (I think the default is the number cores). But I concluded it was not an issue since this is the type of thing that can happen when you run too many tests in parallel. Solving this problem with exclusiveAccess.dirs has a couple of issues. First, you can't use it to exclude individual tests, only directories. Second, even if you put these tests in a subdir and use exclusiveAccess.dirs=. there, it won't stop them from running at the same time as other serviceability/sa tests. As proof of that, I've been working JDK-8227594, which is due to a concurrency issue with a new serviceability/sa/sadebugd test. I added exclusiveAccess.dirs=. in that subdir, and that prevented the two tests in that subdir form running at the same time, solving the problem. However, if you run all of serviceability/sa, it will still run other tests the same time as serviceability/sa/sadebugd tests. My JOBS=8 experiment mentioned above produced resource related failures with the serviceability/sa/sadebug tests when run with all of serviceability/sa, even though neither of the tests in serviceability/sa/saddebug use much memory. They were clearly still be run at the same time as the memory hog tests in the parent dir. So, either we need exclusiveAccess.dirs for all of serviceability/sa, or we need to move the two tests into a directory that is not run at the same time as serviceability/sa (and use exclusiveAccess.dirs=. in that directory). Maybe we need a new root directory for tests that are memory hogs and should not be run with other tests. We can use the same directory structure beneath it. So these two tests can go into something like open/test/jtreg/resourcehogs/serviceability/sa. I'm sure there are other tests that are resource hogs that already are resulting in the entire directory they are in using exclusiveAccess.dirs=.. These tests could be moved and the exclusiveAccess.dirs=. removed.
12-07-2019