JEP [DRAFT]: Container aware Java
kirk at kodewerk.com
Wed Aug 2 09:00:57 UTC 2017
I wasn’t questioning you… and I think we’re saying the same things. Sorry for the noise.
> On Aug 1, 2017, at 11:40 PM, David Holmes <david.holmes at oracle.com> wrote:
> Hi Kirk,
> On 2/08/2017 2:08 AM, Kirk Pepperdine wrote:
>> Is is wise to standardize the JVM around the container du jour?
> Not sure what you mean here. The use of sched_getaffinity doesn't relate to any container technology it is simply a Linux system API with which the cgroups facility has integrated to "do the right thing" when it comes to cpuset usage.
> For things like memory management cgroups is not integrated with the existing system APIs for memory queries so explicit cgroup mechanisms have to be used. I don't think cgroups would be classified as "the container du jour" given it is part of the Linux system. But we would not want to have to build in direct Docker-specific support, for example, but ultimately it comes down to what the user needs. If container technology X is important and the JVM must run well within it then we need to try and support that somehow. If technology X integrates with system APIs so they "do the right thing" then that is great. Otherwise we have no choice but to use whatever API is provided, while maintaining as much flexibility in the VM as possible.
>> Kind regards,
>> Kirk Pepperdine
>>> On Aug 1, 2017, at 9:04 AM, David Holmes <david.holmes at oracle.com> wrote:
>>> Bernd Eckenfels ecki at zusammenkunft.net wrote on Mon Jul 17 21:57:39 UTC 2017
>>>> For a virtualized solution you can use the normal methods for getting the number of virtual CPUs or the RAM size (and I am quite sure nobody expects auto tuning based on host resources). JVM already does that. This fails for soft partitioning, especially cgroups, CPU sets (and NUMA Zones).
>>>> I am not sure how important auto tuning is, but it does make sense to observe soft partitioning limits. None of them are Docker specific, however.
>>>> Besides the maximum heap it also affects parallelity for GC and the default fork/join pool. Anything else in scope for this JEP?
>>> The VM already handles cpusets (as used by cgroups and thus Docker) on Linux, as their use is exposed through the sched_getaffinity API.
More information about the hotspot-dev