RFR: 8321931: memory_swap_current_in_bytes reports 0 as "unlimited" [v3]

[Severin Gehwolf]

On Thu, 18 Jan 2024 16:11:12 GMT, Gerard Ziemski <gziemski at openjdk.org> wrote:

> > 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.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17314#issuecomment-1898911339