RFR (M): 8212657: Implementation of JDK-8204089 Timely Reduce Unused Committed Memory

[Ruslan Synytsky]

Hello, FYI, we found a bug related to the loadaverage threshold.  At the
moment users can specify only an integer value


*manageable(uintx, G1PeriodicGCSystemLoadThreshold*
But in the code it's compared with double *recent_load*.







*double recent_load;if ((G1PeriodicGCSystemLoadThreshold > 0) &&
(os::loadavg(&recent_load, 1) == -1 || recent_load
> G1PeriodicGCSystemLoadThreshold)) {     log_debug(gc, periodic)("Load
%1.2f is higher than threshold "UINTX_FORMAT ". Skipping.", recent_load,
G1PeriodicGCSystemLoadThreshold);     return false;}*
In a normal situation loadaverage will be between 0 and 1 for one CPU core
host system (a loadaverage bigger than 1 means a high load on the host
system). So, users were not able to specify something like 0.5 or even
lower.

Thomas has already prepared a fix JDK-8215548, the fix might be included in
12b25 depending on the required paperwork.

Please let us know if there are any additional questions or concerns.
Regards


On Tue, 18 Dec 2018 at 13:19, Ruslan Synytsky <rs at jelastic.com> wrote:

>
>
> On Tue, 18 Dec 2018 at 12:03, Aleksey Shipilev <shade at redhat.com> wrote:
>
>> On 12/18/18 11:39 AM, Thomas Schatzl wrote:
>> >> One more minor suggestion - G1PeriodicGCInterval should be defined in
>> >> milliseconds at the moment which seems impractical to me. Not clear
>> >> why somebody would need to trigger GC less than in minutes, so people
>> >> will always write a lot of 000. Can we update it to seconds at least?
>> >
>> > You can use SI prefixes like "k" or "M" (probably do not need "G" :) )
>> > to reduce the number of zeros.
>> >
>> > Not really hung up on the scale, I am going to ask for more opinions.
>> > We need to come to a conclusion relatively quickly though as we are
>> > late in the release process already.
>> >
>> > I think the reason for choosing ms is because so far all times were in
>> > ms, and Shenandoah also uses that scale. Otoh J9 uses seconds too.
>>
>> Shenandoah also chose "ms" for consistency reasons.
>>
>> In practical terms, sometimes there is a compelling need to do
>> _concurrent_ GC more frequently than
>> once a second. Think about tiny heap and GC taking just a few
>> milliseconds. Then, to keep memory
>> footprint under control, it would make sense to do GC every, say, 300
>> milliseconds. This is probably
>> a bad idea for the STW GC, but still can be tolerable if GC cycle is in
>> milliseconds range.
>
>
>> Unfortunately, we don't have support for SI prefixes going downwards from
>> 1 (e.g. milli-, micro-),
>> right? Keeping the units in milliseconds, and slapping the SI prefix
>> would be much more confusing
>> with 1K meaning "1 second"...
>>
>
> Ok, having support of prefixes is solving the issue. Just checked it for
> G1PeriodicGCInterval - 1k is the same as 1K = 1 second.
>
> Regards
>
>
>>
>> -Aleksey
>>
>>
>
> --
> Ruslan
> CEO @ Jelastic <https://jelastic.com/>
>


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