JEP 132: More-prompt finalization

[Tony Printezis]

Dmitry,

I totally appreciate that a lot of apps have non-trivial periods of idle 
time. However, you assume that there will be enough resources available 
to handle the peak time load so that we can wait to reclaim them when 
the load drops. I just don't think this is always a reasonable 
assumption. Depending what it's doing, an app can consume a lot of 
resources during peak time, If peak time lasts for a few hours (as it's 
probably the case in your pizza delivery example below).

FWIW,

Tony

On 01/13/2012 09:34 AM, Dmitry Samersoff wrote:
> Tony,
>
>
> On 2012-01-06 14:34, Tony Printezis wrote:
>> Vitaly,
>>
>> Sure, but if the GC detects that the load is low it doesn't know whether
>> the load will remain low for 5 ms or 5 hours (and it's impossible to
>> know, maybe not even the application knows). I can already imagine the
>> bug reports: a spike suddenly happened in the market and the JVM was
>> "locked up" for several seconds!!!
> To be more practical, lets consider a vital case - a shop selling
> something to particular region. (e.g city's best pizza)
>
> It has clear visible pick hours (evening) and clear visible spare time
> (early morning)
>
> So cu would like to have as much free resources as possible at a pick
> hours.  Solution widely used today - create a cluster, then restart
> nodes one by one at a spare time.
>
> What we(java) can do for such case:
>
>     1 (simple, doable today). Give a way to setup ergonomic profile e.g.
> something like -XX:PreferredGCTime. During this time VM sets GC
> parameters to collect as much as possible at the cost of higher
> load by GC thread.
>
>    2. (advanced) Collect heap usage statistics and calculate a
> probability of low load time.
>
> -Dmitry
>