The hotspot container wrapper on Linux is unaware of the VM process moving to a different cgroup - it establishes the paths to the associated controllers at VM start, and those paths never get updated.

This does affect os::available_memory() and os::physical_memory() - used e.g. from Java via JMM - and JFR. It also affects printout in VM.info and the hs-err file. It does *not* effect using the cgroup limit for java heap sizing, AFAICS, since that happens at startup. Unless the cgroup move happens right at startup too.

Note that the container subsystem already takes care of periodically re-reading cgroup limits in case those limits changed. So it already has the notion of knowing the up-to-date limits. Moving the process to a different cgroup should have the same effect.

Reproduction is easy (Ubuntu 20.04):

```
(start VM, has PID 107543)
sudo mkdir /sys/fs/cgroup/memory/foo
echo 107543 | sudo tee /sys/fs/cgroup/memory/foo/cgroup.procs
echo 500000000 | sudo tee /sys/fs/cgroup/memory/foo/memory.limit_in_bytes
jcmd 107543 VM.info
```

VM.info will show the original limit, in this case unlimited:

```
container (cgroup) information:
...
memory_limit_in_bytes: unlimited
```

Since I started the VM in the default systemd cgroup and the VM initialization ran there. However, the real limit applies: the VM will be killed if it allocates more than 500MB.