Re: cost of automatic versus explicit memory management (was How to benchmark memory managers?)

You're absolutely right -- it's not always reasonable to make this
assumption. Our approach increased the cost of *every* pointer mutation,
and that's clearly overkill: it assumes that every single pointer is a
smart pointer. I think that adding this cost to every pointer update
balances out cache misses that could accrue to a (much smaller) number
of smart pointers.

I also agree that performance-sensitive code is likely to be
multithreaded (which is why I snuck in "non-atomic" in my reply :). Of
course, people using C/C++ are very sensitive to the cost of atomic
operations in smart pointer updates, so anyone programming
performance-sensitive applications would avoid doing them. That might
entail some software engineering pain, but we go out our way to point
out that we are not addressing software engineering concerns. I think we
say in the very first sentence something to the effect of GC's software
engineering benefits being beyond dispute.

One thing worth noting is that a lot of performance-sensitive
applications (e.g., many servers) are embarrassingly parallel; for those
apps, atomic updates for smart pointers are usually not necessary. And
in an obligatory Hoard-plug, I'll note that the current version does
away with synchronization (and hence atomic operations) for most
allocations and deallocations.

best,
-- emery

> -----Original Message-----
> From: Boehm, Hans [mailto:[email protected]]
> Sent: Monday, January 10, 2005 4:03 PM
> To: Emery Berger; [email protected]; [email protected]
> Subject: RE: [gclist] How to benchmark memory managers?
> 
> It seems to me that it's not always reasonable to assume that
> the data related to smart pointers will be in the cache.
> 
> For classic reference counting, if you see an assignment
> "p = q;"  I don't think it's safe to conclude that *q will
> also be otherwise accessed.  And it seems even less likely that
> the old *p would be.  And with something like Boost "shared_ptr"s,
> "p = q;" involves increment and decrement operations on fields that
> are located in objects allocated separately from *p and *q,
> so none of this matters much anyway.
> For these systems, I would expect to see a substantial increase
> in cache footprint from reference counting.  (I wish I had
> measurements ...)
> 
> And again, I think that performance-sensitive code is increasingly
> likely to be multithreaded, so in reality the dominant question will
> be whether you need to add synchronization.
> 
> Hans
> 
> > -----Original Message-----
> > From: [email protected]
> > [mailto:[email protected]]On
> > Behalf Of Emery Berger
> > Sent: Monday, January 10, 2005 1:38 PM
> > To: [email protected]; [email protected]
> > Subject: Re: [gclist] How to benchmark memory managers?
> >
> >
> > We might want to take this off-list, but unless I'm
> > misunderstanding the
> > question, I think the issue is whether the oracular approach
> > is ignoring
> > the cost of ownership tracking, as in C++ smart pointers.
> >
> > In fact, we've tested this. We have run experiments where we
> > add a small
> > number of (non-atomic) instructions to every pointer mutation, thus
> > simulating the cost of smart pointers (under the reasonable
assumption
> > that since we're accessing the raw pointer, the related data
> > fields hit
> > in the cache). It turns out that this added overhead does not
> > have much
> > impact at all.
> >
> > -- emery
> >
> > > -----Original Message-----
> > > From: [email protected]
> > [mailto:[email protected]]
> > On
> > > Behalf Of Matthew Hertz
> > > Sent: Monday, January 10, 2005 2:21 PM
> > > To: [email protected]
> > > Subject: Re: [gclist] How to benchmark memory managers?
> > >
> > > > the cost of free only equals the cost of explicit memory
> > management
> > if
> > > > none of the objects ever had shared ownership. Otherwise there
is
> > some
> > > > mechanism being hidden by the oracle that is not being accounted
> > for.
> > >
> > > While you are correct that these sharing costs can add substantial
> > > overheads, the Jikes RVM already performs all of the
> > locking and other
> > > work needed to support its multi-threaded design.  Because these
> > > maintained outside of the memory management routines (and
> > were already
> > > included in both sets of numbers), we did not burden the explicit
> > memory
> > > managers with a duplicative analysis to handle sharing of objects.
> > >
> > > Matthew Hertz
> > > [email protected]
> >
> >