Re: new gc interface

Date view Thread view Subject view Author view

From: Godmar Back (gback@cs.utah.edu)
Date: Wed Jan 27 1999 - 11:17:03 EST


>
> On Jan 25, 1999, Godmar Back <gback@marker.cs.utah.edu> wrote:
>
> > + made the collector/allocator a true COM-like object. [1]
>
> The more I see COM-like objects in Kaffe, the more I think we should
> be using C++ and abstract base classes with virtual methods... The
> effect is exactly the same, except that you don't need the `this'
> pointer explicitly passed as the first argument.
>

I know. It's the same, conceptually.
Unfortunately, though, g++ does not create COM-compatible vtables.

Also, C++ compilers are still slower than C compilers, last time I heard.
Plus, rewriting it would be an effort I don't want to undertake right now.

The other reason I want to avoid C++ is because people like you
will then start using all its bells and whistles, and I'd rather not
argue about why using copy constructors and multiple inheritance is a
bad idea.

> > typedef struct _Collector {
> > struct GarbageCollectorInterface_Ops *ops;
> > } Collector;
>
> Why isn't this just
>
> typedef struct GarbageCollectorInterface_Ops *Collector;
>
> ?

Because a COM object is a pointer to an object, the first element of
which is a pointer to a vtable. Maybe I should have called "ops"
vtable (or dtable, as we call it in kaffe) to make this more clear.

Implementations of the interface will look like this:

struct _CollectorImpl {
        Collector collector; // pointer to shared vtable
        gcList gclists[5];
        void (*walkrootset)(Collector*);
        ...
}

The collector interface will be the basis to do better allocation.
For instance, instead of having main_collector for all threads, we
can easily construct a collector for each thread, essentially creating
per-thread heaps (like Sun does in 1.2)

        - Godmar


Date view Thread view Subject view Author view

This archive was generated by hypermail 2b29 : Sat Sep 23 2000 - 19:57:50 EDT