Re: How to benchmark memory managers?

Calum Grant <[email protected]> Sun, 09 Jan 2005 21:57:12 +0000
Newsgroups gmane.comp.programming.garbage-collection.general
Message-ID <[email protected]>
Emery Berger wrote:
> Hi Calum,
> 
> In response to your first question ("are there any standard approaches
> to testing memory managers?"), the answer is yes.
> 
> The experimental methodology used for the evaluation of memory managers
> is now fairly sophisticated. We measure performance across a range of
> benchmark applications. For Java, this includes the SPECjvm98 suite,
> SPECjbb, and a new collection of applications called the DaCapo
> benchmark suite. Studies of garbage collectors present data points for a
> range of heap sizes (generally presented as multiples of the maximum
> "live" size). When measuring collection pause times, it's also standard
> practice to include a "mutator utilization" curve. You can see examples
> of this methodology in recent publications on the subject in PLDI,
> OOPSLA, and SIGMETRICS, among others.
>  
> Now, the methodology I've just described is used for comparing garbage
> collectors to other garbage collectors. It's a different matter to
> compare (relocating) garbage collectors to explicit memory managers
> (malloc/free): as you note, you cannot use relocating collectors as
> malloc-replacements. You also cannot use malloc/free in a language
> designed for garbage collection, since programs in those languages lack
> calls to free.
> 
> If you'd like to see a way around these difficulties, I'd refer you to a
> paper by my student Matthew Hertz and myself. We have developed a
> methodology that gets around these complications, and we have compared
> the performance of numerous garbage collection algorithms to a
> widely-used explicit memory allocator (the Lea allocator). The paper is
> in submission, but there's an earlier technical report version available
> at http://www.cs.umass.edu/~emery/pubs/04-17.pdf.

Thanks, that looks like very interesting and useful work.

I have knocked together a simple GC for my own application, and the 
obvious question was how to measure it.  I need to check if I am 
improving it, and malloc seems like a good reference point.  I am 
interested in how it performs against manual memory allocation, since 
this is a critical question for the direction of programming languages, 
but as you say this cannot be an exact comparison.

So I knocked up a simple test-suite that creates various data structures 
(trees and lists) of various sizes, and also intersperses this with 
"chaff" (I am sure you have a technical word for this) representing 
short-lived temporaries.  The intention is that this models real 
application behaviour, but unfortunately I don't have the time to 
implement a plug-in for a JVM.  I wonder how it would do in your test?

My results are here: http://visula.org/gc

What I found from benchmarking my GC was that there was a single metric 
that determined the GC's performance relative to malloc.  That metric 
was % live data.  When % live data was 50% or less, my GC outperformed 
malloc.  When the % live data was above 50%, malloc was better.

Regards,
Calum

> regards,
> -- emery
> 
> 
>>-----Original Message-----
>>From: [email protected] [mailto:[email protected]]
> 
> On
> 
>>Behalf Of Calum Grant
>>Sent: Monday, January 03, 2005 1:39 PM
>>To: [email protected]
>>Subject: [gclist] How to benchmark memory managers?
>>
>>I am in the process of writing a garbage collector, and would like a
>>good test-suite for benchmarking it.  I would also like to compare its
>>performance with other memory managers, such as malloc.
>>
>>Are there any standard approaches to testing memory managers?  I can't
>>use it as a malloc-replacement in real applications since it requires
>>marking and relocation which is not easy on opaque binary data (unless
> 
> I
> 
>>go the way of Boehm et al, but that is not the design of this
> 
> collector).
> 
>>I've put together a few simple test cases, allocating a few million
>>objects in some simple data structures, but they just don't seem to be
>>realistic enough.  I want to be able to say "n% faster/slower than
>>malloc on xyz" with confidence.
>>
>>Calum
> 
> 
>