RE: [boost] GC [was:alignment]

From: scleary_at_[hidden]
Date: 2001-05-04 08:23:57

> > Reference counting could probably be accounted for in the header/footer
> > info, and arbitrary allocators can be used if you put alignment
restrictions
> > on them (as I do in Pool's UserAllocator). 
> 
> 	I'm not sure I follow.

You just say that any user-supplied allocator, when asked for 's' bytes of
memory, must return a pointer suitably aligned for any object where
sizeof(object) <= s.  Placing that restriction on the user allows you to
guarantee alignment in turn.

...

> 	The purpose of the library, in the first instance, is to
> allow collection of C++ objects (with finalisation).
> 
...
> However, if one is using constructors/destructors for resource
> acquisition/release, and there are dependencies amoung the
> resources, it isn't enough. Also, it can be very expensive to
> call the collector to release scarce resources in a timely
> manner. Hence, I see a need to add reference counting.
> This would allow release and finalisation of objects
> _immediately_ the object becomes unreachable, provided the object
> isn't part of a cycle.

This is a good idea; when looking at GC, I've thought that destructors
(finalisation) should be called as soon as possible, but with delayed memory
release.

... (Interesting description of Felix snipped)

Felix sounds cool!  I've just discovered Python recently, and I'm a big fan
of languages that mix functional and imperative styles!  Can't say how often
I've wanted to code an algorithm in functional style, but (as we all know),
C++'s StdLib is rather deficient in that area :).

> 	Felix does one other thing: it provides what I call
> 'control inversion'. You write code designed as a thread,
> but the generated code is event driven for efficiency.
> The generated code has been tested with trivial messages
> on a 450MHz Linux box and ran 1 million threads passing
> 2 million messages is a minute. Applications include
> large scale server based GUI's and telephone systems.
> But you can write ordinary programs too :-)

This is really cool -- I do this (at work) by hand for now; my latest
project has up to 130 "virtual threads" but only one in reality.  This is
perfect for uniprocessor systems.  However, may I recommend that you allow
(as compiler switches, or a special run-time module) the ability for users
to have actual kernel threads -- possibly detecting the number of CPUs at
run-time or something.  That will allow your heavy-load programs to scale (I
think we'll see more CPUs on server machines in the future).

        -Steve