Re: Question about memory size and performance

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