Status of JEP-8204088/JDK-8236073

[Thomas Schatzl]

Hi,

On 12.06.21 07:23, Jonathan Joo wrote:
> Hi Thomas and Man,
> 
> Thanks for the feedback.
> 
>     I am still not completely sure why current CPU overhead should influence
>     SoftMaxHeapsize directly and probably I'm just misunderstanding or this
>     is a terminology problem:
> 
> 
> I think this is just a bit of confusion in terminology. Man and I have 
> been using SoftMaxHeapSize interchangeably with the idea of a maximum 
> heap size allowed during a heap resizing event. The way you describe it 
> below seems like a better mental model of the idea:
> 

Thanks for the clarification.

> 
>     Note that SoftMaxHeapSize is just a soft goal, potentially some hard
>     goal would be more useful. Also, there is a long way from limiting the
>     Java heap size to limiting VM memory usage :)
> 
> We were toying with the idea of using SoftMaxHeapSize due to the fact 
> that it already exists in other GC types. But admittedly for the 
> purposes of this project, having a hard heap limit would be better to 
> guarantee no OutOfMemoryErrors. Maybe a better solution to consider is 
> to have a hard heap limit, but then set SoftMaxHeapSize to some value 
> less than this hard limit? This gives us the best of both worlds by 
> allowing us to guarantee a maximum heap usage via the hard limit, but 
> may also make hitting the hard limit less likely. (I imagine hitting the 
> hard heap limit would be a costly operation, whereas hitting the 
> SoftMaxHeapSize limit is less so.)

"CurrentMaxHeapSize" would act similarly to a new -Xmx. I.e. cause full 
gcs and eventually OOME. See 
https://bugs.openjdk.java.net/browse/JDK-8204088 and the related email 
thread.

> 
>     Summing it up, the current available patches are:
>     JDK-8238687 and JDK-8253413: improves (re-)sizing policy and acts on
>     that at any young gc:
>     https://github.com/tschatzl/jdk/tree/8238687-investigate-memory-uncommit-during-young-gc2
> 
>     JDK-8248324 <https://bugs.openjdk.java.net/browse/JDK-8248324>:
>     removes heap resizing at remark, which used a completely
>     different policy anyway. Full gc is still an issue, but "it should not
>     happen". Patch attached to CR.
>     JDK-8236073: implements SoftMaxHeapSize, patch attached to CR.
> 
> 
> Just to make sure I understand correctly -  when you say "patch attached 
> to CR" above, do you mean that they are included in your github repo 
> <https://github.com/tschatzl/jdk/tree/8238687-investigate-memory-uncommit-during-young-gc2>
> Or are they accessible elsewhere which I need to patch myself if I want 
> to test these changes? (I would check myself, but I can't seem to find 
> the actual code snippets in the bugs.openjdk.java.net 
> <http://bugs.openjdk.java.net> links - do I need to have an OpenJDK 
> account to access them?)

Attached to CR means attached to the JIRA issue. These are sometimes 
quite old, so they very likely need some major modifications.

The access issues are interesting, I can see the attachments without 
logging in.

E.g.
https://bugs.openjdk.java.net/secure/attachment/94569/8248324-remove-resizing-during-remark
https://bugs.openjdk.java.net/secure/attachment/94567/8236073-softmaxheapsize
https://bugs.openjdk.java.net/secure/attachment/62184/cpu-time

> 
> These discussions have been immensely valuable to us, so I appreciate 
> your prompt and thorough feedback. I will look further into your 
> GCTimeRatio changes/suggestions to see if they may be sufficient for our 
> needs.

Looking forward to your contributions :p

Thomas