Re: [boost] GC [was:alignment]

From: John Max Skaller (skaller_at_[hidden])
Date: 2001-05-05 15:01:12

scleary_at_[hidden] wrote:
> 
> > > 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.

        I assumed that user allocators must return suitably aligned memory.
It doesn't help me compute a suitable offset m >= n such that given p is
aligned,
then p + m is also aligned.

> >  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.

        Delaying memory release should be up to the allocator.
That is, there's little percentage in not returning the memory
to the deallocation routine immediately: if there's an advantage in
delaying making it available again, the allocator (rather than the
collector)
would know about it.

> 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 :).

        The problem isn't the C++ library, but the core language.
The lack of nested functions, currying, discriminated unions,
sensible declarator syntax, modularity, garbage collection,
(and a few other things :-) make it very hard to use the 
excellent STL properly.

        To use STL properly, most uses would concentrate on
algorithms and iterators. In practice, the most heavily used
part is the containers: the very part that STL is supposed
to abstract away. [The containers are NOT really part of STL at
all, some are supplied merely as a convenience.]

> >       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.

> 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).

        A typical system has input threads which get the input data and 
feed into into a central queue. A dispatcher then dispatches messages 
to one of several worker threads (typically one per CPU), 
_each_ of which then dispatches its share to the ultra-lightweight (UL)
(Felix) threads.

        Felix requires the client provide _all_ of this architecture.
So there is no need for a compiler switch. On the other hand,
Felix does currently provide for three frames for sharing: global,
process, and OS-thread, which are passed to the UL threads.
This is built in, which is wrong.

-- 
John (Max) Skaller, mailto:skaller_at_[hidden]
10/1 Toxteth Rd Glebe NSW 2037 Australia voice: 61-2-9660-0850
checkout Vyper http://Vyper.sourceforge.net
download Interscript http://Interscript.sourceforge.net