8321931: memory_swap_current_in_bytes reports 0 as "unlimited" #17314

gerard-ziemski · 2024-01-08T21:28:46Z

We make a distinction between 0 for a limit vs non-limit cgroup values.

For all values (limit or non-limit), 0 simply means 0.

Output before from jcmd PID VM.info:

container (cgroup) information:
container_type: cgroupv2
cpu_cpuset_cpus: not supported
cpu_memory_nodes: not supported
active_processor_count: 8
cpu_quota: not supported
cpu_period: not supported
cpu_shares: not supported
memory_limit_in_bytes: unlimited
memory_and_swap_limit_in_bytes: unlimited
memory_soft_limit_in_bytes: unlimited
memory_usage_in_bytes: 11129120 k
memory_max_usage_in_bytes: not supported
memory_swap_current_in_bytes: unlimited
memory_swap_max_limit_in_bytes: unlimited
maximum number of tasks: 18963
current number of tasks: 33

Output now from jcmd PID VM.info:

container (cgroup) information:
container_type: cgroupv2
cpu_cpuset_cpus: not supported
cpu_memory_nodes: not supported
active_processor_count: 8
cpu_quota: not supported
cpu_period: not supported
cpu_shares: not supported
memory_limit_in_bytes: unlimited
memory_and_swap_limit_in_bytes: unlimited
memory_soft_limit_in_bytes: unlimited
memory_usage_in_bytes: 4962584 k
memory_max_usage_in_bytes: not supported
memory_swap_current_in_bytes: 0
memory_swap_max_limit_in_bytes: unlimited
maximum number of tasks: 18963
current number of tasks: 33

In this example `memory_swap_current_in_bytes` should be printed as equal to 0, not "unlimited".

Progress

Change must be properly reviewed (1 review required, with at least 1 Reviewer)
Change must not contain extraneous whitespace
Commit message must refer to an issue

Issue

JDK-8321931: memory_swap_current_in_bytes reports 0 as "unlimited" (Bug - P4)

Reviewers

Severin Gehwolf (@jerboaa - Reviewer)
Ioi Lam (@iklam - Reviewer)

Reviewing

Using git

Checkout this PR locally:
$ git fetch https://git.openjdk.org/jdk.git pull/17314/head:pull/17314
$ git checkout pull/17314

Update a local copy of the PR:
$ git checkout pull/17314
$ git pull https://git.openjdk.org/jdk.git pull/17314/head

Using Skara CLI tools

Checkout this PR locally:
$ git pr checkout 17314

View PR using the GUI difftool:
$ git pr show -t 17314

Using diff file

Download this PR as a diff file:
https://git.openjdk.org/jdk/pull/17314.diff

Webrev

Link to Webrev Comment

bridgekeeper · 2024-01-08T21:30:16Z

👋 Welcome back gziemski! A progress list of the required criteria for merging this PR into master will be added to the body of your pull request. There are additional pull request commands available for use with this pull request.

openjdk · 2024-01-08T21:31:41Z

@gerard-ziemski The following label will be automatically applied to this pull request:

hotspot-runtime

When this pull request is ready to be reviewed, an "RFR" email will be sent to the corresponding mailing list. If you would like to change these labels, use the /label pull request command.

mlbridge · 2024-01-08T21:51:38Z

Webrevs

gerard-ziemski · 2024-01-16T17:34:33Z

@iklam @poonamparhar @jerboaa can you please review this fix? It's pretty simple bug fix I think.

tstuefe

Are we sure 0 means unlimited? I looked at https://www.kernel.org/doc/Documentation/cgroup-v1/memory.txt
and did not find any remarks.

https://unix.stackexchange.com/questions/420906/what-is-the-value-for-the-cgroups-limit-in-bytes-if-the-memory-is-not-restricte seems to indicate the value is some very high number. Or is this handled by the JVMs cgroup layer?

tstuefe · 2024-01-16T18:07:25Z

src/hotspot/os/linux/osContainer_linux.cpp

  st->print("%s: ", metrics);
-  if (j > 0) {
+  if ((j > 0) || ((j == 0) && (limit == false))) {


Clearer would be a reversal like this:

if (j == 0 && limit) { "unlimited" } else { print }

I think I decided to have it this way to draw the attention to the fact that the value 0 for a non-limit kind should be treated as numerical value and not a special case.

This provides, in my opinion, a self-documenting code without the need for an explicit comment. That was my rationale at least, but if that doesn't come across, then we can simplify and add an actual comment?

Up to you. Both are okay, this was just a small nit :)

tstuefe · 2024-01-16T18:13:06Z

src/hotspot/os/linux/osContainer_linux.hpp

@@ -45,7 +45,7 @@ class OSContainer: AllStatic {
 public:
  static void init();
  static void print_version_specific_info(outputStream* st);
-  static void print_container_helper(outputStream* st, jlong j, const char* metrics);
+  static void print_container_helper(outputStream* st, jlong j, const char* metrics, boolean limit = false);


Can we name this parameter better, or add a comment at least?

Maybe boolean zero_means_unlimited = false?

Would isLimit be any better?

jerboaa · 2024-01-16T19:41:49Z

I'll have a look tomorrow. In general unlimited means -1 not 0. cg v1 doesn't explicitly set it to a specified value if it is unlimited. It's a very large number. For cg v2 it's usually the string max as specified by the kernel docs of interface files.

gerard-ziemski · 2024-01-16T21:59:48Z

Are we sure 0 means unlimited? I looked at https://www.kernel.org/doc/Documentation/cgroup-v1/memory.txt and did not find any remarks.

https://unix.stackexchange.com/questions/420906/what-is-the-value-for-the-cgroups-limit-in-bytes-if-the-memory-is-not-restricte seems to indicate the value is some very high number. Or is this handled by the JVMs cgroup layer?

Now I'm not 100% sure. I think it was a source code comment somewhere where I saw this special 0 treatment. I will have to refresh my memory...

Thank you for taking a look!

gerard-ziemski · 2024-01-16T22:36:48Z

I'll have a look tomorrow. In general unlimited means -1 not 0. cg v1 doesn't explicitly set it to a specified value if it is unlimited. It's a very large number. For cg v2 it's usually the string max as specified by the kernel docs of interface files.

Thank you for taking a look. I think I saw this special treatment of 0 value somewhere in source code. I will have to look.

(I wish I posted this PR sooner when all this was still fresh in my memory, but by the same token, I'm happy that at least we are taking a look at this right now and not a year from now...)

iklam · 2024-01-17T07:52:24Z

I'll have a look tomorrow. In general unlimited means -1 not 0. cg v1 doesn't explicitly set it to a specified value if it is unlimited. It's a very large number. For cg v2 it's usually the string max as specified by the kernel docs of interface files.

Thank you for taking a look.

According to
https://git.kernel.org/pub/scm/linux/kernel/git/tj/cgroup.git/tree/Documentation/admin-guide/cgroup-v2.rst

 memory.swap.max
	A read-write single value file which exists on non-root
	cgroups.  The default is "max".

	Swap usage hard limit.  If a cgroup's swap usage reaches this
	limit, anonymous memory of the cgroup will not be swapped out.

E.g.,

$ cat /sys/fs/cgroup/user.slice/memory.swap.max
max

I don't think there's a file under /sys/fs/cgroup where the numberic value of "0" means "unlimited". Instead, "0" means zero or "not allowed at all".

Otherwise, how can you express "don't allow any swapping for this container"?

I think the proper fix is:

void OSContainer::print_container_helper(outputStream* st, jlong j, const char* metrics) {
  st->print("%s: ", metrics);
- if (j > 0) {
+ if (j >= 0) {

I think I saw this special treatment of 0 value somewhere in source code. I will have to look.

It's worthwhile scanning the source code to for such cases and possibly fixing them.

In most cases, I see that -1 means unlimited, and -2 (OSCONTAINER_ERROR) means error:

jlong CgroupSubsystem::limit_from_str(char* limit_str) {
  if (limit_str == nullptr) {
    return OSCONTAINER_ERROR;
  }
  // Unlimited memory in cgroups is the literal string 'max' for
  // some controllers, for example the pids controller.
  if (strcmp("max", limit_str) == 0) {
    os::free(limit_str);
    return (jlong)-1;
  }
  julong limit;
  if (sscanf(limit_str, JULONG_FORMAT, &limit) != 1) {
    os::free(limit_str);
    return OSCONTAINER_ERROR;
  }
  os::free(limit_str);
  return (jlong)limit;
}

jerboaa

The bug is a bit thin on the details. Can that be improved? I'm not aware that any of the APIs in hotspot return 0 for unlimited. If it is, it's a bug. It would be good to have this captured in a test somewhere. Would a test with --memory 200M --memory-swap=200M (no swap), trigger the said case? I think it would. For cg v1 the test case would probably also need a swappiness value of 0.

src/hotspot/os/linux/osContainer_linux.cpp

gerard-ziemski · 2024-01-18T15:51:13Z

I'll have a look tomorrow. In general unlimited means -1 not 0. cg v1 doesn't explicitly set it to a specified value if it is unlimited. It's a very large number. For cg v2 it's usually the string max as specified by the kernel docs of interface files.

Thank you for taking a look.

According to https://git.kernel.org/pub/scm/linux/kernel/git/tj/cgroup.git/tree/Documentation/admin-guide/cgroup-v2.rst
 memory.swap.max
	A read-write single value file which exists on non-root
	cgroups.  The default is "max".

	Swap usage hard limit.  If a cgroup's swap usage reaches this
	limit, anonymous memory of the cgroup will not be swapped out.
E.g.,
$ cat /sys/fs/cgroup/user.slice/memory.swap.max
max
I don't think there's a file under /sys/fs/cgroup where the numberic value of "0" means "unlimited". Instead, "0" means zero or "not allowed at all".

Otherwise, how can you express "don't allow any swapping for this container"?

I think the proper fix is:
void OSContainer::print_container_helper(outputStream* st, jlong j, const char* metrics) {
  st->print("%s: ", metrics);
- if (j > 0) {
+ if (j >= 0) {
I think I saw this special treatment of 0 value somewhere in source code. I will have to look.

It's worthwhile scanning the source code to for such cases and possibly fixing them.

In most cases, I see that -1 means unlimited, and -2 (OSCONTAINER_ERROR) means error:
jlong CgroupSubsystem::limit_from_str(char* limit_str) {
  if (limit_str == nullptr) {
    return OSCONTAINER_ERROR;
  }
  // Unlimited memory in cgroups is the literal string 'max' for
  // some controllers, for example the pids controller.
  if (strcmp("max", limit_str) == 0) {
    os::free(limit_str);
    return (jlong)-1;
  }
  julong limit;
  if (sscanf(limit_str, JULONG_FORMAT, &limit) != 1) {
    os::free(limit_str);
    return OSCONTAINER_ERROR;
  }
  os::free(limit_str);
  return (jlong)limit;
}

My original fix was just being extra careful and was fixing non-limit type values only.

However, looking at https://git.kernel.org/pub/scm/linux/kernel/git/tj/cgroup.git/tree/Documentation/admin-guide/cgroup-v2.rst I noticed a section on Limits which says:

Limits are in the range [0, max] and defaults to "max", which is noop.

so 0 is a valid value, with no special meaning, so your suggestion on accepting 0 in all cases looks valid to me. Looks like the original implementation got this incorrect.

Thank you for the review and feedback!

gerard-ziemski · 2024-01-18T16:11:12Z

The bug is a bit thin on the details. Can that be improved? I'm not aware that any of the APIs in hotspot return 0 for unlimited. If it is, it's a bug. It would be good to have this captured in a test somewhere. Would a test with --memory 200M --memory-swap=200M (no swap), trigger the said case? I think it would. For cg v1 the test case would probably also need a swappiness value of 0.

Actually hotspot is doing the opposite: it returns "unlimited" when it was supposed to return "0". You can see it right now if you run "jcmd PID VM.info" and look at "memory_swap_current_in_bytes". No special flags needed to see this.

Thank you for taking a look. I also agree that we should treat "0" as "0" for all cases.

…ype values

jerboaa · 2024-01-18T17:25:57Z

The bug is a bit thin on the details. Can that be improved? I'm not aware that any of the APIs in hotspot return 0 for unlimited. If it is, it's a bug. It would be good to have this captured in a test somewhere. Would a test with --memory 200M --memory-swap=200M (no swap), trigger the said case? I think it would. For cg v1 the test case would probably also need a swappiness value of 0.

@gerard-ziemski Please add a test case for this in test/hotspot/jtreg/containers/docker/TestMisc.java akin to testPrintContainerInfoActiveProcessorCount(), setting the above memory limits and asserting that you get memory_swap_current_in_bytes: 0 in the output. Since this is a cgv2 specific output you might need to add a condition on Metrics.systemMetrics().getProvider().equals("cgroupv2") and otherwise skip it.

Actually hotspot is doing the opposite: it returns "unlimited" when it was supposed to return "0". You can see it right now if you run "jcmd PID VM.info" and look at "memory_swap_current_in_bytes". No special flags needed to see this.

Sorry for not being clear. This particular case exercises CgroupV2Subsystem::print_version_specific_info, which internally calls:

  char* mem_swp_current_str = mem_swp_current_val();
  jlong swap_current = limit_from_str(mem_swp_current_str);

swap_current is then being passed to OSContainer::print_container_helper. So I meant the retrieval code which would return -1 if it was unlimited (i.e. swap_current == -1 if it was unlimited). In this case I'm pretty sure it returns 0, but OSContainer::print_container_helper has the bug. That's what I meant with hotspot APIs. I should have been more precise.

gerard-ziemski · 2024-01-19T17:56:20Z

The bug is a bit thin on the details. Can that be improved? I'm not aware that any of the APIs in hotspot return 0 for unlimited. If it is, it's a bug. It would be good to have this captured in a test somewhere. Would a test with --memory 200M --memory-swap=200M (no swap), trigger the said case? I think it would. For cg v1 the test case would probably also need a swappiness value of 0.

@gerard-ziemski Please add a test case for this in test/hotspot/jtreg/containers/docker/TestMisc.java akin to testPrintContainerInfoActiveProcessorCount(), setting the above memory limits and asserting that you get memory_swap_current_in_bytes: 0 in the output. Since this is a cgv2 specific output you might need to add a condition on Metrics.systemMetrics().getProvider().equals("cgroupv2") and otherwise skip it.

Actually hotspot is doing the opposite: it returns "unlimited" when it was supposed to return "0". You can see it right now if you run "jcmd PID VM.info" and look at "memory_swap_current_in_bytes". No special flags needed to see this.

Sorry for not being clear. This particular case exercises CgroupV2Subsystem::print_version_specific_info, which internally calls:
  char* mem_swp_current_str = mem_swp_current_val();
  jlong swap_current = limit_from_str(mem_swp_current_str);
swap_current is then being passed to OSContainer::print_container_helper. So I meant the retrieval code which would return -1 if it was unlimited (i.e. swap_current == -1 if it was unlimited). In this case I'm pretty sure it returns 0, but OSContainer::print_container_helper has the bug. That's what I meant with hotspot APIs. I should have been more precise.

Thank you for the feedback and the suggestion.

I chose to check that unlimited does not appear with memory_swap_current_in_bytes on the same line, not for 0 to exist, since it's possible that the current memory swap might be > 0, at some point later in the future.

jerboaa · 2024-01-22T14:04:47Z

I chose to check that unlimited does not appear with memory_swap_current_in_bytes on the same line, not for 0 to exist, since it's possible that the current memory swap might be > 0, at some point later in the future.

Why? If a container is being run with --memory X and --memory-swap X (X being the same value) then there must not be any swap used, so any value greater than 0 would be a bug and the assertion is safe. See https://docs.docker.com/config/containers/resource_constraints/#prevent-a-container-from-using-swap

I agree, though, that it might be better to move to a separate test. Up to you.

gerard-ziemski · 2024-01-22T17:13:10Z

I chose to check that unlimited does not appear with memory_swap_current_in_bytes on the same line, not for 0 to exist, since it's possible that the current memory swap might be > 0, at some point later in the future.

Why? If a container is being run with --memory X and --memory-swap X (X being the same value) then there must not be any swap used, so any value greater than 0 would be a bug and the assertion is safe. See https://docs.docker.com/config/containers/resource_constraints/#prevent-a-container-from-using-swap

This bug fix is correcting the behavior where 0 should be displayed instead of unlimited. Strictly speaking that's all we need to test here. The test I proposed uses an approach that is flexible enough in case that this value happens to be greater than 0 in the future for any reason.

I'd really prefer to keep the test as simple as possible to cover this specific fix, which in my opinion it does.

Setting --memory X and --memory-swap X introduces more variables and makes the test more complicated than it needs to be, in my opinion.

What do you think?

jerboaa · 2024-01-22T20:34:31Z

This bug fix is correcting the behavior where 0 should be displayed instead of unlimited. Strictly speaking that's all we need to test here. The test I proposed uses an approach that is flexible enough in case that this value happens to be greater than 0 in the future for any reason.

I disagree. What you are looking for is if the actual value is 0 you want memory_swap_current_in_bytes to report 0. The test you have might end up running with any number > 0 in the interface file, and your test would spuriously pass even with the actual bug present (since unlimited would not occur in this case). The only way to actually ensure you get 0 is by running the test in a container with swap turned off.

gerard-ziemski · 2024-01-23T16:25:56Z

This bug fix is correcting the behavior where 0 should be displayed instead of unlimited. Strictly speaking that's all we need to test here. The test I proposed uses an approach that is flexible enough in case that this value happens to be greater than 0 in the future for any reason.

I disagree. What you are looking for is if the actual value is 0 you want memory_swap_current_in_bytes to report 0. The test you have might end up running with any number > 0 in the interface file, and your test would spuriously pass even with the actual bug present (since unlimited would not occur in this case). The only way to actually ensure you get 0 is by running the test in a container with swap turned off.

As long as the test gets run in an environment where we do get 0 at least some times, we are fine, but you are correct: to guarantee that we test the right thing, we would need to setup the container properly.

I feel like I don't have enough container knowledge to write such a test, without investing more time learning the basics. Would you kindly help and write the test you want please? At least the part that sets up the environment and starts the test (on Linux only?) with swap==0 ?

jerboaa · 2024-01-23T18:01:14Z

I feel like I don't have enough container knowledge to write such a test, without investing more time learning the basics. Would you kindly help and write the test you want please? At least the part that sets up the environment and starts the test (on Linux only?) with swap==0 ?

Sure. Here you go:
gerard-ziemski#1

gerard-ziemski · 2024-01-25T16:06:09Z

I feel like I don't have enough container knowledge to write such a test, without investing more time learning the basics. Would you kindly help and write the test you want please? At least the part that sets up the environment and starts the test (on Linux only?) with swap==0 ?

Sure. Here you go: gerard-ziemski#1

Thank you very much!

I will incorporate it into this fix shortly...

gerard-ziemski · 2024-01-25T16:39:22Z

I have added your test with one change.

Instead of checking for strict syntax:

out.shouldContain("memory_swap_current_in_bytes: 0"))

we do:

            for (String s : str.split(System.lineSeparator())) {
                if (s.contains("memory_swap_current_in_bytes")) {
                    s.shouldContain("0");
                    s.shouldNotContain("unlimited");
                }
            }

I did this in anticipation of JDK-8321932 which will change the layout.

I feel like I don't have enough container knowledge to write such a test, without investing more time learning the basics. Would you kindly help and write the test you want please? At least the part that sets up the environment and starts the test (on Linux only?) with swap==0 ?

Sure. Here you go: gerard-ziemski#1

Thank you very much!

I will incorporate it into this fix shortly...

Ready for a re-review.

jerboaa

The test would be a bit easier to read if we extracted the loose matching to a function. Suggestion:

[...]
               out.shouldContain("memory_swap_max_limit_in_bytes");
               checkLineForValue(str, "memory_swap_max_limit_in_bytes", "0");
[...]

private static void checkLineForValue(String output, String match, String value) {
[...]
}

test/hotspot/jtreg/containers/docker/TestContainerInfo.java

openjdk · 2024-01-29T10:15:22Z

@gerard-ziemski This change now passes all automated pre-integration checks.

ℹ️ This project also has non-automated pre-integration requirements. Please see the file CONTRIBUTING.md for details.

After integration, the commit message for the final commit will be:

8321931: memory_swap_current_in_bytes reports 0 as "unlimited"

Reviewed-by: sgehwolf, iklam

You can use pull request commands such as /summary, /contributor and /issue to adjust it as needed.

At the time when this comment was updated there had been 25 new commits pushed to the master branch:

51671c0: 8323809: Serial: Refactor card table verification
cdf918b: 8325134: Serial: Remove Generation::used_region
4da28b4: 8291809: Convert compiler/c2/cr7200264/TestSSE2IntVect.java to IR verification test
0377f1a: 8325133: Missing MEMFLAGS parameter in parts of os API
df35462: 8323502: javac crash with wrongly typed method block in Flow
af32262: 8325049: stubGenerator_ppc.cpp should use alignas
85e3201: 8325159: C2 SuperWord: measure time for CITime
8796f43: 8315762: Update subtype check profile collection on s390x following 8308869
80642dd: 8324817: Parallel GC does not pre-touch all heap pages when AlwaysPreTouch enabled and large page disabled
692c9f8: 8325201: (zipfs) Disable TestPosix.setPermissionsShouldConvertToUnix which fails on Windows
... and 15 more: https://git.openjdk.org/jdk/compare/6b09a79d64bcb1aa5382e60d1d690d4e4a9dc337...master

As there are no conflicts, your changes will automatically be rebased on top of these commits when integrating. If you prefer to avoid this automatic rebasing, please check the documentation for the /integrate command for further details.

➡️ To integrate this PR with the above commit message to the master branch, type /integrate in a new comment.

iklam · 2024-01-16T18:29:51Z

src/hotspot/os/linux/osContainer_linux.hpp

@@ -45,7 +45,7 @@ class OSContainer: AllStatic {
 public:
  static void init();
  static void print_version_specific_info(outputStream* st);
-  static void print_container_helper(outputStream* st, jlong j, const char* metrics);
+  static void print_container_helper(outputStream* st, jlong j, const char* metrics, boolean limit = false);


Maybe boolean zero_means_unlimited = false?

tstuefe · 2024-01-29T15:20:59Z

I have to beg out, too much to do before FOSDEM. But you have two reviewers already, so..

gerard-ziemski · 2024-01-29T18:19:45Z

Thank you all for the reviews!

I will re-run Mach5 teir1-5 tests, just in case, before I push it...

gerard-ziemski · 2024-02-02T15:40:59Z

I had to make a small fix in the test - I forgot to pass required argument.

Tested it with MACH5 tier1-5 and that looks fine.

jerboaa

Still fine.

gerard-ziemski · 2024-02-05T19:35:25Z

/integrate

openjdk · 2024-02-05T19:35:45Z

Going to push as commit 7777eb5.
Since your change was applied there have been 32 commits pushed to the master branch:

51853f7: 8324724: Add Stub routines for FP16 conversions on aarch64
c3adc61: 8325199: (zipfs) jdk/nio/zipfs/TestPosix.java failed 6 sub-tests
1993652: 8324983: race in CompileBroker::possibly_add_compiler_threads
55c1446: 8321468: Remove StringUTF16::equals
19e9220: 8325169: Reduce String::indexOf overheads
89e6a02: 8325064: C2 SuperWord: refactor construct_bb
d395ac2: 8321373: Build should use LC_ALL=C.UTF-8
51671c0: 8323809: Serial: Refactor card table verification
cdf918b: 8325134: Serial: Remove Generation::used_region
4da28b4: 8291809: Convert compiler/c2/cr7200264/TestSSE2IntVect.java to IR verification test
... and 22 more: https://git.openjdk.org/jdk/compare/6b09a79d64bcb1aa5382e60d1d690d4e4a9dc337...master

Your commit was automatically rebased without conflicts.

openjdk · 2024-02-05T19:35:51Z

@gerard-ziemski Pushed as commit 7777eb5.

💡 You may see a message that your pull request was closed with unmerged commits. This can be safely ignored.

distinquish between 0 and unlimited

92133df

openjdk bot added the hotspot-runtime hotspot-runtime-dev@openjdk.org label Jan 8, 2024

gerard-ziemski marked this pull request as ready for review January 8, 2024 21:48

openjdk bot added the rfr Pull request is ready for review label Jan 8, 2024

tstuefe reviewed Jan 16, 2024

View reviewed changes

jerboaa suggested changes Jan 17, 2024

View reviewed changes

src/hotspot/os/linux/osContainer_linux.cpp Show resolved Hide resolved

gerard-ziemski added 2 commits January 18, 2024 10:17

0 means 0 and has no special meaning either for limit, or non-limit t…

81d4362

…ype values

forgot to remove unused attribute

0c5c02f

add test per jerboaa feedback

94da8d9

openjdk bot removed the rfr Pull request is ready for review label Jan 19, 2024

fix white spaces

733dd18

openjdk bot added the rfr Pull request is ready for review label Jan 22, 2024

openjdk bot removed the rfr Pull request is ready for review label Jan 25, 2024

whitespace

e461be2

openjdk bot added the rfr Pull request is ready for review label Jan 25, 2024

gerard-ziemski requested review from tstuefe and jerboaa January 25, 2024 16:39

jerboaa reviewed Jan 25, 2024

View reviewed changes

test/hotspot/jtreg/containers/docker/TestContainerInfo.java Outdated Show resolved Hide resolved

test/hotspot/jtreg/containers/docker/TestContainerInfo.java Outdated Show resolved Hide resolved

jerboaa feedback

9833820

gerard-ziemski requested a review from jerboaa January 27, 2024 02:36

jerboaa approved these changes Jan 29, 2024

View reviewed changes

openjdk bot added the ready Pull request is ready to be integrated label Jan 29, 2024

iklam approved these changes Jan 29, 2024

View reviewed changes

Merge remote-tracking branch 'upstream/master' into JDK-8321931

ea3762c

gerard-ziemski added 2 commits February 1, 2024 10:33

Merge remote-tracking branch 'upstream/master' into JDK-8321931

1cf9256

need to pass in argument

078a79b

gerard-ziemski requested review from iklam and jerboaa February 2, 2024 15:41

jerboaa approved these changes Feb 5, 2024

View reviewed changes

iklam approved these changes Feb 5, 2024

View reviewed changes

openjdk bot added the integrated Pull request has been integrated label Feb 5, 2024

openjdk bot closed this Feb 5, 2024

openjdk bot removed ready Pull request is ready to be integrated rfr Pull request is ready for review labels Feb 5, 2024

8321931: memory_swap_current_in_bytes reports 0 as "unlimited" #17314

8321931: memory_swap_current_in_bytes reports 0 as "unlimited" #17314

Conversation

gerard-ziemski commented Jan 8, 2024 • edited by openjdk bot Loading

Progress

Issue

Reviewers

Reviewing

Webrev

bridgekeeper bot commented Jan 8, 2024

openjdk bot commented Jan 8, 2024

mlbridge bot commented Jan 8, 2024 • edited Loading

Webrevs

gerard-ziemski commented Jan 16, 2024

tstuefe left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

jerboaa commented Jan 16, 2024

gerard-ziemski commented Jan 16, 2024

gerard-ziemski commented Jan 16, 2024

iklam commented Jan 17, 2024

jerboaa left a comment

Choose a reason for hiding this comment

gerard-ziemski commented Jan 18, 2024

gerard-ziemski commented Jan 18, 2024

jerboaa commented Jan 18, 2024

gerard-ziemski commented Jan 19, 2024

jerboaa commented Jan 22, 2024 • edited Loading

gerard-ziemski commented Jan 22, 2024 • edited Loading

jerboaa commented Jan 22, 2024

gerard-ziemski commented Jan 23, 2024

jerboaa commented Jan 23, 2024

gerard-ziemski commented Jan 25, 2024

gerard-ziemski commented Jan 25, 2024

jerboaa left a comment

Choose a reason for hiding this comment

openjdk bot commented Jan 29, 2024 • edited Loading

Choose a reason for hiding this comment

tstuefe commented Jan 29, 2024

gerard-ziemski commented Jan 29, 2024

gerard-ziemski commented Feb 2, 2024

jerboaa left a comment

Choose a reason for hiding this comment

gerard-ziemski commented Feb 5, 2024

openjdk bot commented Feb 5, 2024

openjdk bot commented Feb 5, 2024

gerard-ziemski commented Jan 8, 2024 •

edited by openjdk bot

Loading

mlbridge bot commented Jan 8, 2024 •

edited

Loading

jerboaa commented Jan 22, 2024 •

edited

Loading

gerard-ziemski commented Jan 22, 2024 •

edited

Loading

openjdk bot commented Jan 29, 2024 •

edited

Loading