JDK-8246648 : issue with OperatingSystemImpl getFreeSwapSpaceSize in docker after 8242480
  • Type: Bug
  • Component: hotspot
  • Sub-Component: runtime
  • Affected Version: 15,16
  • Priority: P4
  • Status: Resolved
  • Resolution: Fixed
  • OS: linux
  • CPU: generic
  • Submitted: 2020-06-05
  • Updated: 2024-10-17
  • Resolved: 2020-06-08
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 15 JDK 8 Other
11.0.10-oracleFixed 13.0.6Fixed 15 b27Fixed 8u281Fixed openjdk8u282Fixed
Related Reports
Relates :  
JDK-8242480 - Negative value may be returned by getFreeSwapSpaceSize() in the docker
Description
In the TestMemoryAwareness.java docker related test the following issue has been observed
on a Linux machine:

java.lang.RuntimeException: 'OperatingSystemMXBean\\.getFreeSwapSpaceSize: [1-9][0-9]+' missing from stdout/stderr 
 
               at jdk.test.lib.process.OutputAnalyzer.shouldMatch(OutputAnalyzer.java:306)
               at TestMemoryAwareness.testOperatingSystemMXBeanAwareness(TestMemoryAwareness.java:154)
               at TestMemoryAwareness.main(TestMemoryAwareness.java:65)
               at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
               at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:64)
               at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
               at java.base/java.lang.reflect.Method.invoke(Method.java:564)
               at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:127)
               at java.base/java.lang.Thread.run(Thread.java:832)

Jie Fu proposed an adjustment to OperatingSystemImpl getFreeSwapSpaceSize to address this.
Comments
Fix request (13u) Requesting backport to 13u as follow-up fix for JDK-8242480. The patch applies cleanly. Tested with container tests, the affected test passed.
03-12-2020
I wasn't disagreeing with your personal experience. It's a conclusion you've come up on your own and I'm sorry if that's how it came across. Certainly not intended. I disagree that there is any rule that disallows interdependent issues being flagged for approval at the same time when they are ready. That was the case for this bug. JDK-8242480 was flagged for approval as it was review approved. That's the general agreement about a bug being ready for approval. Putting on my maintainer hat, it makes sense to approve such bugs in tandem (or deny them in tandem). The reason why there isn't such a rule is: time to get approval. If they'd have to be serialized, there is a chance of losing days just doing: 1) add a label 2) get them approved, due to time zone/work hours difference with the approver. Just to be clear, it wasn't expected for JDK-8242480 to be set back to "needs-review". One way to resolve this issue would be for the maintainer to add the jdk8u-fix-request label back themselves and approve it in tandem once the dependent issue is - in their view - ready for approval (as long as it's clearly stated in the Fix Request comment that an issue needs a follow-up fix). As to your comment about long-term-work-in-process issues clogging up the queue. Those were issues where A) the patch didn't apply cleanly B) No review approval was in sight. Thus, they were not ready for approval. Different issue.
01-12-2020
I'm not sure you can disagree with a statement of my personal experience. In making this process less cumbersome for yourself, your actions are making the approval queue intractable for me. Could you not use your own labels to manage your patch queue rather than those used for approvals? You reminded me some time ago that there is more than one person who has to use this queue, when there were a number of long-term work-in-progress patches on the queue. We cleared all those out. I'm simply asking you not to create the same situation again. If the queue is kept manageable, everyone's work will move through the process faster.
01-12-2020
[~andrew] I disagree. It's a tandem approval. Either both or none. I am trying to manage 10-ish backports in my queue, some waiting for approval some on review. Getting them commented and tagged helps this process. In this case both bugs are ready for approval and the intention would be to push them both at the same time. Needing to remember which ones have been tagged and which one not, makes this even more cumbersome.
26-11-2020
Please don't queue up multiple approvals like this. It clogs up the approval queue and thus holds up any of them from getting approved.
25-11-2020
Fix Request (OpenJDK 8u): Please approve backporting this to 8u. It applies clean after JDK-8242480 is in. JDK-8242480 is waiting for approval too. Low risk, moves the calculation of the container limits delta into the conditional where limits >=0 (i.e. in an actual container).
03-11-2020
Fix request (11u) -- will label after testing completed. I would like to downport this for parity with 11.0.10-oracle. Applies clean.
02-10-2020
URL: https://hg.openjdk.java.net/jdk/jdk/rev/2def4c9b817b User: mbaesken Date: 2020-06-08 07:31:15 +0000
08-06-2020
The comment from Jie specifically was: And I think the logic in src/jdk.management/unix/classes/com/sun/management/internal/OperatingSystemImpl.java should be fixed. In my fix for JDK-8242480, I had ignored the case for kernels which don't support "--memory-swap 150M". In that case, containerMetrics.getMemoryAndSwapLimit()[1] will return -1. [1] http://hg.openjdk.java.net/jdk/jdk/file/a95911422005/src/jdk.management/unix/classes/com/sun/management/internal/OperatingSystemImpl.java#l73
05-06-2020