Application memory use

Kirk Pepperdine kirk at kodewerk.com
Mon Apr 23 03:38:52 PDT 2012


CMS will leave floating garbage which will be picked up on the next collection. The parallel collectors will be exact and thus the working or live set size after GC will always be larger when using CMS.


On 2012-04-23, at 11:41 AM, Michael Hall wrote:

> 
> On Apr 23, 2012, at 4:28 AM, Henri Gomez wrote:
> 
>>> Both showed as 64 bit in Activity Monitor.
>>> This may very well be the largest part of it but the JConsole heap graphs
>>> looked considerably different between the two applications and the
>>> information seemed to indicate different methods for gc. I guess I was
>>> wondering if there is anything we should know about this as well?
>> 
>> 64bits Hotspot (6u23 and later) JVMs switch automatically to
>> Compressed Pointers (-XX:+UseCompressedOops), saving memory.
>> 
>> http://docs.oracle.com/javase/7/docs/technotes/guides/vm/performance-enhancements-7.html
> 
> I will read that. Thanks. I'm wondering now if I can determine if this does more or less completely explain the difference.
> Can I get the Java 6 to show about the same memory use as the Java 7?
> If there is an option to turn the switch off that you mention I could try that.
> Otherwise I was wondering if starting the Java 6 jvm -d64, iirc, or whatever it is to indicate it should use 64 bit would also accomplish eliminating the compression?
> For a while watching JConsole it appeared Java 7 wasn't going to give any memory back at while while 6 showed to briefly climb and drop back down in a narrower range in the sawtooth pattern mentioned earlier. I would think this might mean some difference in the maximum memory footprint.



More information about the macosx-port-dev mailing list