[Proposal] Better systemd slice memory limit support for OpenJDK

Bob Vandette bob.vandette at oracle.com
Thu Jan 17 15:59:43 UTC 2019


I checked a few systems I have access to and they all have use_hierarchy enabled.  When I set a memory
limit the memory.stat hierarchical_memory_limit is identical to the memory.limit_in_bytes contents.

Do you have any idea why the kernel behavior changed?  Is this documented behavior?

I wouldn’t want to add a work-around for a transient kernel bug.

Bob.


> On Jan 17, 2019, at 9:57 AM, Severin Gehwolf <sgehwolf at redhat.com> wrote:
> 
> Hi,
> 
> Current container awareness for OpenJDK seems to work for systemd
> slices too, on some systems. To be precise, this works for older
> Kernels e.g. 3.10. However, we've noticed that this breaks for newer
> Kernel versions[1] such as the one in F28, currently 4.19.14-200. If
> the container support would also look at hierarchical memory limits
> exposed via memory.stat in the cgroup file system, it would again
> work[2]. A proof of concept implementation is here:
> 
> http://cr.openjdk.java.net/~sgehwolf/webrevs/container-systemd-slice-01/webrev/
> 
> This enhancement wouldn't change any existing container memory limit
> detection as it only kicks in when all other look-ups determined that
> there is no limit in place. I've verified this by running Docker
> container tests. The idea is to look for hierarchical_memory_limit and
> hierarchical_memsw_limit lines in the memory.stat file of the cgroup
> tree.
> 
> Would it be possible to consider such an enhancement upstream? If so,
> I'll file a bug and propose it for review.
> 
> This issue has been originally raised here:
> https://bugzilla.redhat.com/show_bug.cgi?id=1509371
> 
> Thanks,
> Severin
> 
> [1] Java process gets killed by oom killer.
>    See: http://cr.openjdk.java.net/~sgehwolf/webrevs/container-systemd-slice-01/before.txt
> [2] Java process throws OutOfMemoryError as expected.
>    See: http://cr.openjdk.java.net/~sgehwolf/webrevs/container-systemd-slice-01/after.txt
> 



More information about the hotspot-dev mailing list