changing the memory settings semi-dynamically vs GateKeeper and signing
jon.masamitsu at oracle.com
Thu Feb 23 17:59:35 UTC 2012
On 02/22/12 21:07, Andrew Thompson wrote:
> On Feb 22, 2012, at 4:45 PM, Jon Masamitsu wrote:
> Thanks for the response Jon. I realize this isn't any easy problem to
> solve because of the huge variations in kinds of programs out there,
> not to mention reasonable people differ on what is desirable behavior.
> Still, I feel the settings we have for the VM are heavily slanted
> towards server deployment where total amount of RAM on the host is a
> known quantity, and the total number of apps is usually fixed.
> Contrast the client where:
> - every PC or Mac may have a different amount of RAM
> - users may be starting up and shutting down programs constantly
> - users expect to be able to open huge files, limited only by the
> amount of RAM they bought.
> With that model, guessing what to put in -Xmx is borderline impossible.
> More comments inline below
>> On 2/21/2012 9:49 PM, Srinivas Ramakrishna wrote:
>>> Good points... It's a good idea to cross- post this over to
>>> hotspot-gc-dev since it's relevant to "client ergonomics" or current
>>> lack thereof....
>>> Sent from my iPhone
>>> On Feb 21, 2012, at 20:54, Andrew Thompson<lordpixel+openjdk at mac.com
>>> <mailto:lordpixel+openjdk at mac.com>> wrote:
>>>> But why should this be the behavior? Apps written in Objective C
>>>> don't self limit, so why not make Xmx default to physical RAM size?
>> Hotspot reserves the address space for the heap at initialization.
>> Having it automatically
>> grab 1gb seems unfriendly to other users of address space within the
>> process and may
>> exclude other process from starting up (depending on how over
>> subscription of memory
>> is handled).
> Is that really a concern on a 64bit VM? I know it is a huge concern on
> 32bit (e.g. I have never gotten WIndows XP to go beyond a 1GB Xmx
> reliably on 32 bit) but for 64 bit the address space is at least
> several GB, right?
> It seems to me that the design of G1 would one day allow discontiguous
> heaps where the memory need not be reserved at startup as a single
> piece, but isn't that already irrelevant on 64bit?
You're absolutely right. 64bit is not a concern. And in 32bit it's as
much a matter of
having the card table cover the heap as the heap itself.
>> 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
> 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
> 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.
The part about the heap not shrinking is a bug.
>> Regarding shrinking the heap and giving back the memory, yes, the
>> hotspot should do
> 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 believe you are referring to a contribution from a Google engineer.
It got complicated in a non-technical way.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the hotspot-gc-dev