Re: Question about memory size and performance

Let me be the dissenter here. I think it sounds like a smart solution  
thats looking for a problem. Often it seems that any smart sounding  
optimization turns out to be sub-optimal in a different circumstance.  
Yes all modern OSes have virtual memory. But I don't think I have seen  
a production application deployed where the process RSS/maximum memory  
footprint + baseline system memory consumption  > physical memory.  
Certainly not in the past seven years. Perhaps I have just been  
fortunate in working for clients with too much cash? But if page  
scanning is never occurring then this problem is moot.

Jeff mentioned that Hotspot's GC effectiveness depends on memory  
access patterns. The other point is that different applications need  
to optimize for different performance variables. For example, in an  
automatic trading system it might be crucial that a full GC never  
cause execution to pause for seconds. Rather than building connections  
between VMs and kernels, there are crude, ugly ways to achieve this by  
reducing heap size (multiple smaller JVMs on a single host) or even  
ensuring that processes get restarted before they reach a high water  
mark.

On Dec 11, 2007, at 10:25 AM, Mann, Ivan H wrote:

> I recall the studies from the 60's on memory allocation, and the  
> answer then was that after a while memory fragmentation gets to be a  
> serious problem as requests for memory blocks of different sizes are  
> made and they use most of pieces of existing blocks, but leave small  
> pieces that can be too small.  The result is that you can have a lot  
> of memory not being used but not available because it exists in  
> blocks smaller than the requests that you make.
>
> The result of that is that in order for memory allocation to work  
> when you are making frequent requests is to have a lot of very large  
> chunks of memory.  The alternative is to spend a lot of time looking  
> for exactly the right piece of free memory to allocate the request  
> in.  The Java method of garbage collection means that every now and  
> then you wait a while for it to find all of those large chunks of  
> memory, but when it does you have large chunks of memory available,  
> which is exactly what you want.  You pay a price of CPU time when  
> garbage collection happens, but you get in return a significant  
> savings of time when allocating small pieces.  Java does that a  
> whole lot.
>
> Ivan Mann
>
>
> -----Original Message-----
> From: Discussion of advanced Java topics. [mailto:[email protected] 
> ] On Behalf Of Endre Stølsvik
> Sent: Monday, December 10, 2007 7:11 PM
> To: [email protected]
> Subject: Re: [ADVANCED-JAVA] Question about memory size and  
> performance
>
> Carfield Yim wrote:
>> According to this paper -
>> http://www.cs.umass.edu/~emery/pubs/gcvsmalloc.pdf , it claim that :
>>
>> "If their applications will be deployed on systems with at least  
>> three
>> times as much RAM as needed, then garbage collection should provide
>> reasonable performance. However, if the deployed systems will have
>> less RAM, or if their applications will have to compete with other
>> processes for memory, then practitioners should expect garbage
>> collection to exact a substantial performance cost."
>>
>> Just wonder if anybody have comment about this claim?
>
> I sure wonder too. First I thought that "boy, this must be totally  
> wonky", but reading the paper, it got more interesting.
>
> Is GC really this bad compared to explicit malloc/free?
>
>> Say my
>> applicatioon typical requirement 1024m heap size to run. My computer
>> need to have 3072m to have reasonable performance???
>
> This 3-5 times the RAM is based on the _minimum_ the application  
> needs to actually complete. 3 times that minimum amount will get you  
> going good, according to the paper.
>
> But yes: Someone that are proper JVM/GC wizards, please comment on  
> this paper! (Semi-proper wizards and even medium knowledgeable java  
> coders are also invited to read and comment on it!)
>
>
> Also, one of the guys that wrote that paper, Matthew Hertz, have  
> also written another paper on a subject I liked a lot: GC on VM, as  
> in Virtual Memory. I've found that Java sucks when it comes to  
> "managing"
> the memory on a OS with VM, which is pretty much all OSes that matter.
> Since most GCs occasionally will have to do a full collect, ALL  
> pages that the JVM have allocated over time will have to be fetched  
> from disk, "thrashing" the VM's efforts of sticking unused pages to  
> disk.
>   I believe I might be seeing an effect of this after a virus scan  
> have run on my box during the night: most applications are somewhat  
> sluggish to restore, except Eclipse, which often are curiously quick  
> to wake up.
>   This is obviously not such a big deal on single-purpose systems,  
> but for "Desktop Java" to rule, something should probably be done -  
> a Java program cannot go around assuming that it is the only  
> application running on a box. (This also goes for the huge memory  
> footprint any sized java GUI application is making - multiplying the  
> GC/VM problem).
> This problem should also be present for other GCed languages,  
> like .Net.
>
> However, our guy has an answer: Make the GC interact with the kernel  
> - that is, make the kernel have access points to let the processes  
> known which pages of theirs are in and out of memory. This seems  
> such an obvious idea that I wonder why all OS'es haven't got the  
> feature implemented already.
>
> Matthew Hertz:
>   http://www-cs.canisius.edu/~hertzm/
> The "Bookmarking Collector":
>   http://www-cs.canisius.edu/~hertzm/bc.html
>
> Kind regards,
> Endre.
>
> ===================================
> This list is hosted by DevelopMentor  http://www.develop.com
>
> View archives and manage your subscription(s) at http://discuss.develop.com
>
> ===================================
> This list is hosted by DevelopMentor®  http://www.develop.com
>
> View archives and manage your subscription(s) at http://discuss.develop.com
>

===================================
This list is hosted by DevelopMentor®  http://www.develop.com

View archives and manage your subscription(s) at http://discuss.develop.com