ZGC EAB +2 FEEDBACK

Thu Nov 3 10:45:43 UTC 2022

Hi there,

 First, thanks for the job. I am really excited following your videos, the github repo, mails... I think this will be a game changer, because although ZGC is already there and pauses are great, in some cases extra memory and CPU to run the workload is too high.

 I have been doing some happy testing with Build 20-genzgc+2-20 (2022/10/31) -> No crashes compared with first build.

 I am using Linux 686 (Manjaro with a recent kernel) running on a VBox VM.

 To do the tests, I am using Apache Geode (distributed cache) with 2 servers (one using Gen ZGC and another G1). I run simple test populating the cache. The test is adding entries and the Apache Geode is synchronously replicating information in both servers before answering the client populating the cache. 

 - TEST 1: (-Xmx4096m -XX:+UseZGC for server with GenZGC) Using Xmx=4G. Everything looks fine for me. 

 - TEST 2: (-Xmx4096m -XX:SoftMaxHeapSize=3500m -XX:+UseZGC for server with GenZGC). Everything looks fine for me until JVM decides to utilize all memory when SoftMaxHeapSize is NOT sustainable anymore. What is strange for me at this point, is that YoungGen is kept extremely small while (around 20MB) and OldGen is basically taking almost all the heap (I would expect once that all memory is utilized then is shared between Young and Old and heuristics will find the right balance). The side effect is that objects are immediately promoted to OldGen because basically there is no room. On the other hand, a huge amount of Minor collections is done (almost not freeing any memory), and obviously Major Collections are also needed to keep application running. I am NOT sure if -XX:SoftMaxHeapSize is expected to be supported in GenZGC. In case the answer is yes, probably something need to be improved to better support the use case (e.g. giving more buffer to youngGen). Maybe you have a different goal in your mind for this setting.

 Just let me know if you need extra information (jconsole pictures, logs...)

 Regards,

 Evaristo

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/zgc-dev/attachments/20221103/55aec30f/attachment-0001.htm>