atom feed25 messages in net.java.openjdk.hotspot-gc-devRe: Free ratio based heap shrinking i...
FromSent OnAttachments
Hiroshi YamauchiMar 10, 2010 3:16 pm 
Jon MasamitsuMar 10, 2010 4:03 pm 
Jon MasamitsuMar 10, 2010 11:05 pm 
Hiroshi YamauchiMar 11, 2010 3:08 pm 
Jon MasamitsuMar 15, 2010 12:03 pm 
Hiroshi YamauchiMar 15, 2010 4:49 pm 
Jon MasamitsuMar 16, 2010 3:38 pm 
Jon MasamitsuMar 16, 2010 8:03 pm 
Hiroshi YamauchiMar 18, 2010 11:27 am 
Hiroshi YamauchiMar 18, 2010 12:01 pm 
Jon MasamitsuMar 19, 2010 10:03 am 
Hiroshi YamauchiMar 24, 2010 5:00 pm 
Jon MasamitsuMar 26, 2010 4:54 pm 
Hiroshi YamauchiMar 31, 2010 11:25 am 
Jon MasamitsuApr 1, 2010 9:02 am 
Hiroshi YamauchiApr 13, 2010 11:20 am 
Hiroshi YamauchiApr 28, 2010 1:36 pm 
Jon MasamitsuApr 29, 2010 1:57 pm 
Hiroshi YamauchiApr 29, 2010 2:47 pm 
Jon MasamitsuMay 3, 2010 10:52 am 
Hiroshi YamauchiMay 10, 2010 4:50 pm 
Jon MasamitsuMay 13, 2010 8:52 am 
Hiroshi YamauchiMay 13, 2010 4:34 pm 
Jon MasamitsuMay 13, 2010 10:42 pm 
Hiroshi YamauchiMay 17, 2010 5:26 pm 
Subject:Re: Free ratio based heap shrinking in the parallel collector
From:Hiroshi Yamauchi (yama@google.com)
Date:Mar 24, 2010 5:00:55 pm
List:net.java.openjdk.hotspot-gc-dev

Hi Jon,

You're right that adjust_for_throughput() will not shrink the heap.

Another part of the policy is that the heap is shrunk if the throughput goal and the pause time goal are being met. It's a slower process than just enforcing MaxHeapFreeRatio and requires a number of GC's (that is, the heap would be shrunk down a percentage at each GC).

GC usually happens only as needed. So, after the application goes idle, GC does not probably happen. The next GC happens only after the application goes active again. Assuming that, there aren't many chances to shrink the heap (maybe only one). If the application calls System.gc() right before going idle, that may be the only chance. In such cases, the slower process may not work very well.

We would need to change the UseAdaptiveSizePolicy to do something like

if ( average-pause > pause-goal) shrink heap else if (average-throughput < throughput-goal) && ! (UseFreeRatioForParallelGC && heap too empty)) <<<< new grow heap else shrink heap

Or maybe something like

if ( average-pause > pause-goal) shrink heap else if (average-throughput < throughput-goal) if (UseFreeRatioForParallelGC && heap too empty) <<<< new shrink heap (policy-to-be-determined) <<<< else <<<< grow heap else if (average-throughput < throughput-goal) grow heap to reduce gc overhead else shrink heap

OK. I think the latter may be able to shrink the heap more aggressively.

Do you think the free ratio-based shrinking should happen only when the throughput goal is met? Using the above scenario, when the application is working hard (and perhaps GC is working hard as well) and goes idle next moment, the average throughput at the time of the phase change may not be good enough for the goal to be met (hence no shrinking).

Thanks, Hiroshi