On Tuesday, March 25, 2003, at 01:56  Uhr, Andreas Raab wrote:

>>> Well a write barrier just needs a write not a read modify
>>> write cycle so it should be better
>>
>> But it has to monitor every write.
>
> Yup, but this can be _really_ cheap.

But the operative word is *can* be.

[using MMU hardware]

I am quite aware of this, and I've actually played with something like 
this (for a somewhat different purpose) myself.  Boehm's CGC can use 
this strategy, and I think VW also does something in this direction.

However, this comes at another cost:  portability.  You then require 
hardware that has an MMU (embedded systems may not), and you need to 
have access to that MMU from a user-level program.  You may also have 
the cost of a system call to set/clear the bits.  Depending on your 
workload, this can cost you more than you're gaining.

[snip]

>>>  but that depends on the hardware write buffers working
>>> well. I'm assuming a card marking write barrier. New space
>>> doesn't need any write barrier protection.
>>
>> Sure, but I think it's really not a very clear-cut matter, with a lot
>> of dependencies on how the hardware works and how programs behave.
>
> One thing to keep in mind here is that the tradeoff really is in the
> combination of freeing AND allocating objects.

Of course, but this is obvious, isn't it?  All I am saying is that the 
matter is not as clear-cut as Tim made it out to be.

>>> The copy only happens when collecting so it only effects
>>> live objects and with a generational collector we are hoping
>>> that most objects die young.
>>
>> Sure, but you are copying the entire object from one place to
>> another, instead of modifying a single word.
>> Also, hope is just that:  hope.
>
> Well, that's true and yet, I have in my entire use of Smalltalk

That's the point:  the paper Tim was criticising was describing 
Inferno, not Smalltalk.  Just as my descriptions come from the world of 
Objective-C, where a specific reference-counting scheme dominates.

>  (which is
> 10+ years) exactly once found this to be a real problem - which was 
> solved
> by reading up and experimenting a bit with a few GC parameters.

Well, I've been programming Objective-C for 15+ years and I rarely run 
into problems with reference counting, which I then solve.  So?

>  About the
> only place where I find the the incremental behavior cumbersome if 
> when you
> essentially deal with tons of "media data" - just bits (primitive 
> numbers
> and floats) which - if not represented as a homogenous type - tend to
> explode in your face. But fortunately, Squeak has float arrays and 
> vector
> operations for many of those things ;)

Well, my experience is primarily with media-data, typically handling 
both input and output files much larger than available RAM, and with a 
VM system that is very good about the distinction between "clean" and 
"dirty" VM pages.  In such a system, copying data around and making it 
*dirty* just for the heck of it is about the worst sin you can commit, 
as you have just moved from a system that is moving along nicely to one 
that is in VM-thrash-death.

Which doesn't mean that all systems are like that, far from it.  I am 
just saying that parameters can be very different.

>> Not a guarantee.
>
> There's no guarantee for a non-copying memory manager either ;-)

I didn't say there was, although the non-copying "manager" does have 
the guarantee of not copying, which (see above) can be quite important.

> It's just a
> question of the tradeoffs - in a compacting GC/allocator you reason 
> that you
> don't want to spend time on allocation/freeing individual objects 
> which is
> true for small, short-lived objects.

Exactly.  It is a matter of trade-offs, and how the trade-offs work for 
you depends very much on your context.  One size doesn't fit all.  For 
example, if you don't have a lot of small, short-lived objects (which 
Smalltalk in particular generates at an exceptional rate), then your 
parameters are different.

>  In a non-compacting scheme you reason
> that you don't want to spend time in copying objects and compacting 
> memory;
> which is true for large long-lived objects. In any case, if the basic
> assumptions change you have a problem.

Exactly.  Except that I have found fairly easy workarounds for 
temporary objects, at least in Objective-C.

>> If environmental parameters change (larger objects,
>> not so many dying quite so young) then it doesn't work out the same
>> way.  For (one) example, Objective-C objects tend to be
>> larger and also tend to stick around longer.
>>
>> So I think the matter is not quite so cut and dry.
>
> Well, actually it is.

Not really, there are other issues as well.

>  It's quite simple: If you have many small, short-lived
> objects then a compacting GC/allocator is the way to go. If you have 
> few,
> large, long-lived objects (let's call them data structures ;) then it
> clearly isn't. And vice versa: If you have a compacting allocator make 
> sure
> your app doesn't use huge data structures. If you don't, make sure it 
> does.

Well, what if I need memory addresses of my objects to remain constant?

Marcel

-- 
Marcel Weiher				Metaobject Software Technologies
marcel at metaobject.com		www.metaobject.com
Metaprogramming for the Graphic Arts.   HOM, IDEAs, MetaAd etc.