Question regarding JEP 8204089 Timely Reducing Unused Committed Memory

[Kirk Pepperdine]

Hi,

I’ve tuned a dozens of applications where I wished that G1 returned to a minimum memory configuration when it could. Thus I strongly support the notion of returning uncommitted memory to the OS, this email flows into my previous arguments about speculatively triggered collections. IME, speculatively triggered GC, such as the one proposed in this JEP, has very very very rarely worked out to be a good thing. The trigger in every case has been based on some assumption that is fundamentally flawed. I would revert to the two main culprits, speculative calls to System or Runtime.gc() and DGC (RMI) resetting the guaranteed GC interval value (of max long ms by default). These have a high probability of triggering unnecessary full collections that often create some havoc in the runtime. The assumption in this case is that the application is quiet but as we can see in this email, and as I’ve witnessed in many other applications, runtimes rarely quiet and the machine can decide to do something at the most inappropriate time.

Additionally, there is a suspicion here, especially after discussions that included Gil (Tene) that the benchmark used to “validate” this proposed implementation may have issues.. It would be useful if that benchmark could be released so that we can actually examine it to determine what, if any, issues may exist. I’m very happy to help vet this benchmark.

In an era when the GC engineers are working so very hard to make as much of the collection process as concurrent as possible, it just feels very wrong to rely on a huge STW event to get something done. In that spirit, it behoves us to explore how committed memory maybe released at the tail end of a normally triggered GC cycle. I beleive at the end of a mixed cycle was mentioned. I believe this would give those that want/need to minimize their JVM’s footprint an even greater cost advantage then attempting to reduce the footprint at some (un???)random point in time.

Kind regards,
Kirk

> On Jun 1, 2018, at 7:41 AM, Sunny Chan, CLSA <sunny.chan at clsa.com> wrote:
> 
> (resending for hotspot-gc-dev)
>  
> Hello,
>  
> I have a number of question about the proposed changes for the JEP and I would like to make the following suggestions and comments
>  
> 1)      Are we planning to make this change the default behavior for G1? Or this is an optional switch for people who runs in a container environment?
> 2)      In a trading systems, sometimes there are period of quiescence and then suddenly a burst of activity towards market close or market event. The loadavg you suggest to “monitor” the activity in the system only reports up to 14mins and it might not necessary a good measure for this type of applications, especially you would trigger a Full GC
> 3)      You haven’t fill in the details for “The GCFrequency value is ignored and therefore, i.e., no full collection is triggered, if:”
> 4)      If we are trigging full GC with this we should make sure the GC reason is populated and log properly in the GC log so we can track it down.
> 5)      I have not heard of J9 Gencon/Shenandoah providing similar functionality. Can you point me to further documentation on which feature you model upon?
>  
> Thanks.
>  
> Sunny Chan
> Senior Lead Engineer, Executive Services
> D  +852 2600 8907  |  M  +852 6386 1835  |  T  +852 2600 8888
> 5/F, One Island East, 18 Westlands Road, Island East, Hong Kong
>  
> <image002.png> <https://hk.linkedin.com/company/clsa><image004.png> <https://twitter.com/clsainsights?lang=en><image006.png> <https://www.youtube.com/channel/UC0qWp_lLnOcRYmBlCNQgZKA><image008.png> <https://www.facebook.com/clsacommunity/>
>  
> clsa.com <https://www.clsa.com/>
> Insights. Liquidity. Capital.
>  
> <image010.png> <https://www.clsa.com/member>
>  
> A CITIC Securities Company
>  
> The content of this communication is intended for the recipient and is subject to CLSA Legal and Regulatory Notices.
> These can be viewed at https://www.clsa.com/disclaimer.html <https://www.clsa.com/disclaimer.html> or sent to you upon request.
> Please consider before printing. CLSA is ISO14001 certified and committed to reducing its impact on the environment.
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/hotspot-gc-dev/attachments/20180601/5bd8caa6/attachment.htm>