Question regarding JEP 8204089 Timely Reducing Unused Committed Memory

Fri Jun 1 13:44:40 UTC 2018

Hi Kirk, thank you for the additional important highlights.

On 1 June 2018 at 08:21, Kirk Pepperdine <kirk.pepperdine at gmail.com> wrote:

> 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.
>
As we discuss this is optional, so when somebody is not sure it's a right
thing to do simply ignore the existence of this option, like many others.

>
> 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.
>
Your help with additional review of the benchmarking process will be useful
and highly appreciated. Rodrigo will share specifics.

>
> 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.
>
How hard/expensive is to implement in G1 something similar like Shenandoah
does?

Thanks

>
> 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
> <https://maps.google.com/?q=18+Westlands+Road&entry=gmail&source=g>,
> 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 or sent to
> you upon request.
> Please consider before printing. CLSA is ISO14001 certified and committed
> to reducing its impact on the environment.
>
>
>

-- 
Ruslan
CEO @ Jelastic <https://jelastic.com/>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/hotspot-gc-dev/attachments/20180601/bd8025ec/attachment.htm>