Status of JEP-8204088/JDK-8236073

[Thomas Schatzl]

Hi,

On 15.06.21 21:45, Man Cao wrote:
> Hi all,
> 
> Thank you for the feedback!
> 
[...]>
> The problem we are trying to solve for the "Container RAM limit is 
> fixed" case,
> is actually orthogonal to the relationship between the two flags.
> Basically, we need a flag that can be adjusted dynamically (i.e. 
> "manageable" in HotSpot).

I think something like GCTimeRatio could be made manageable and it would 
be useful to do so. That came up internally in some discussions already 
a fair amount of time ago afair, but with the current heap sizing broken 
it's just one more (small) todo...

> Then we can make either a JVM feature, or a non-JVM approach such as via 
> an agent,
> to automatically set either GCTimeRatio/GCCpuPercentage 
> or SoftMaxHeapSize/CurrentMaxHeapSize
> based on the container RAM usage/limit ratio.
> 
> Assuming using the GCCpuPercentage and CurrentMaxHeapSize flag names, 
> suppose we have a
> JVM feature -XX:+StriveToStayWithinContainerRAMLimit, its behavior could be:
> - If container RAM usage/limit ratio is below 90%, nothing needs to be 
> done and just use
>    the default values for GCCpuPercentage and CurrentMaxHeapSize.
> - If container RAM usage/limit ratio is 90%-95%, it could start trying 
> to reduce the heap size,
>    either by increasing GCCpuPercentage, or shrinking CurrentMaxHeapSize.
> - If container RAM usage/limit ratio is above 95%, it could try even 
> harder by further increasing
>    GCCpuPercentage or shrinking CurrentMaxHeapSize.
> In the above cases, there will be a limit on how 
> far -XX:+StriveToStayWithinContainerRAMLimit
> could increase GCCpuPercentage or shrink CurrentMaxHeapSize.
> We don't want to cause GC thrashing, as it is better to be killed by the 
> container manager and
> restart the program, than to be stuck in GC thrashing. We could rely on 
> UseGCOverheadLimit
> (JDK-8212084) for this purpose as well.
> 
> I'm not sure if we could make GCCpuPercentage manageable, but
> CurrentMaxHeapSize will definitely be manageable. If
> GCCpuPercentage is manageable, then -XX:+StriveToStayWithinContainerRAMLimit
> could be built solely by changing GCCpuPercentage, without relying on 
> setting CurrentMaxHeapSize.

My general opinion about these kind of fairly complex heuristics not 
directly related how the VM should operate "right now" is to try to keep 
them outside the VM :) This heuristic in particular would need to know 
the container RAM limit (ok, that one the VM knows already) and in 
particular its own total RAM usage which is not the case today.

Both variables seem to be something that is very easily (and probably 
better) determined by some outside entity and any response to that could 
be more flexibly managed there at first glance; similar external agents 
tend to be running anyway already somewhere for container/VM management too.

Another reason to not immediately jump on it is that while I can see 
your point, first I would prefer to have the current issues fixed :)

> 
> For getting CPU usage
>  > The problem is that apart from internal prototypes we never got around
>  > to add that. There's JDK-8027759 (and one more I think) though, even
>  > with a very very old patch.
>  >
>  > Another issue related to getting cpu usage I remember is support on some
>  > systems, and it may be spotty on others (i.e. granularity wise).
>  >
>  > Do you have any experience on that outside of Linux?
> 
> Great point. I haven't thought of this problem yet.
> https://github.com/caoman/jdk/tree/G1ThreadsCPUTime 
> contains a patch on how
> we get the CPU times.
> I see os::is_thread_cpu_time_supported() could return false on Windows 
> and BSD.
> We will dig further to see how this could be implemented for these OSes.

Having looked a bit about that, OSX should be fairly easy (thread_info() 
call), but probably unsupportable on Windows: its getThreadTimes() seems 
to be unusable and the only way there.

Thomas