changing the memory settings semi-dynamically vs GateKeeper and signing

[Andrew Thompson]

On Feb 23, 2012, at 12:07 AM, Andrew Thompson wrote:

Apologies for replying to myself, but I realized I have a persistent typo (mx where I meant ms) which renders the last part of the email unintelligible


> 
>> A smaller  limit on the size of the heap also limits the pause time an application will see.
>> It can also limits throughput but I believe there are many users who prefer the low pause
>> more often rather than the larger pauses less often.
> 
> I can more or less control this today. I can do something like
> 
> -Xmx = 128m
> -XX:GCTimeRatio=19, 
> -XX:MaxGCPauseMillis=1000

Here I meant -Xms=128m, allowing Xmx to take a much larger value thru ergonomics, or alternatively specifying a large -Xmx

> 
> Then the parallel collector will respond by not growing the heap as much... it prefers to collect over grow on more occasions.
> So it is possible to keep some of the benefits of a smaller heap.
> 
> But the real issue is these 2 flags do nothing to the parallel collector, which creates the highwatermark effect
> 
> -XX:MaxHeapFreeRatio=YY
> -XX:MinHeapFreeRatio=ZZ
> 
> Since mx is small the actual used amount of memory (not address space) starts low, can go up, but can't go down again unless one is running serlal gc.
> This is what I think we are missing in the desktops apps. mx is hard to predict so rather than do what why not let Hotspot grab a block of address space for a potentially large heap and let it (the heap's data) grow and shrink as needed.

Here again I meant to say "Since ms is small..."

> 
>> Regarding shrinking the heap and giving back the memory, yes, the hotspot should do
>> that.
> \
> So was there a fundamental flaw with last year's patch? It caused more gcs but was there a showstopper problem with it or did the developer just lose interest?
> 

I am happy to enter a couple of enhancement requests if you would like the feedback to be recorded

- that G1 and/or Parallelgc should be able to shrink the heap, respecting MaxHeapFreeRatio/MinHeapFreeRatio or some similar settings
- that it would be good to have some kind of switch, say -XXaggressiveErgonomics  ;-),  which cause the Xms value to default low, the Xmx value to default to a significant fraction of physical ram and let the VM grow and shrink the heap within these large bounds
- I suppose a 3rd ticket could be about G1 being able to manage discontiguous heaps, because ultimately isn't this the ultimate flexibility... being able to really add and remove blocks of address space to the heap on demand?


AndyT (lordpixel - the cat who walks through walls)
A little bigger on the inside

	(see you later space cowboy, you can't take the sky from me)