Bug ID: JDK-8333522 JFR SwapSpace event might read wrong free swap space size

Versions (Unresolved/Resolved/Fixed)

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 23	JDK 24
23.0.2Fixed	24 b02Fixed

I've just observed a test failure on a cgroups v2 test system where the containers/docker/TestJFREvents.java test failed with:

----------System.err:(12/674)----------
java.lang.Exception: Found free size value is bad
        at TestJFREvents.testSwapMemory(TestJFREvents.java:257)
        at TestJFREvents.main(TestJFREvents.java:84)
        at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:103)
        at java.base/java.lang.reflect.Method.invoke(Method.java:580)
        at com.sun.javatest.regtest.agent.MainWrapper$MainTask.run(MainWrapper.java:138)
        at java.base/java.lang.Thread.run(Thread.java:1575)

JavaTest Message: Test threw exception: java.lang.Exception: Found free size value is bad

Upon further looking the test contained this output too:

------------------------->8-------------------
Found freeSize value 6207565824 is bad
------------------------->8-------------------

The events that got recorded looked like this:

===== EventType: jdk.SwapSpace
startTime = 893777303
totalSize = 104857600
freeSize = 6207565824
===== EventType: jdk.SwapSpace
startTime = 895074451
totalSize = 104857600
freeSize = 104857600

Note that this particular test system has 6207565824 as the host free swap size value. However, the totalSize got already recorded as
104857600 (which is the container limit value).

Therefore, the code needs to be fixed to never report more than the totalSize value (which might be a containerized value).

It's not clear to me why we ended up in this state however. Nevertheless this is a bug and should be fixed. JDK-8325139 was the original bug that introduced this.

A pull request was submitted for review. Branch: master URL: https://git.openjdk.org/jdk23u/pull/88 Date: 2024-08-30 13:01:19 +0000
30-08-2024
jdk23u backport request I would like to have the patch in jdk23u as well, because the issue is present there too. The backport is low risk and clean.
30-08-2024
Since JDK-8325139 is new in JDK 23, please consider backporting to the stabilization repo after some time.
10-06-2024
Changeset: de55db23 Author: Matthias Baesken <mbaesken@openjdk.org> Date: 2024-06-10 08:14:23 +0000 URL: https://git.openjdk.org/jdk/commit/de55db2352f84c101f8197ee7aca80d72807fbc5
10-06-2024
A pull request was submitted for review. URL: https://git.openjdk.org/jdk/pull/19574 Date: 2024-06-06 09:23:03 +0000
06-06-2024
Feel free to create a PR. I doubt testing will help much as I've only seen it once so far.
05-06-2024
> The obvious choice would be to instead of the upper bound of host free swap use min(os::total_swap_space_size(), host_free_swap()) Hi Severin thanks for the suggestion. Do you want to create a PR ? Or should I create one - if so, could you test it in your environment ?
05-06-2024
[~mbaesken] The obvious choice would be to instead of the upper bound of host free swap use min(os::total_swap_space_size(), host_free_swap()). Here: https://github.com/openjdk/jdk/commit/3d106cb091de6b6ef2a9bf483fb0f5c98c28263c#diff-aeec57d804d56002f26a85359fc4ac8b48cfc249d57c656a30a63fc6bf3457adR317
05-06-2024
> Therefore, the code needs to be fixed to never report more than the totalSize value (which might be a containerized value). Hi Severin, so should I simply add a check and reduce freeSize to totalSize if it is larger like you observed?
05-06-2024
ILW = MLM = P4
04-06-2024