Safe garbage collecting

[Robert Potthast]

Hi!
I am trying to implement a safe garbage collecting system. I use
reference counting combined with smart pointers and a garbage collector
which keeps a list of all heap-allocated objects. Now I still have the
problem to distinguish between stack and heap allocated objects ( see
also "Determining if object has been allocated using operator new" ).
I either have the choice to disallow multiple/virtual inheritance (bad)
OR disallow stack allocated objects and directly "embedded" objects
(worse).
It seems I won't be able to solve those problems, so I want to know if
there is another concept for memory management. Any hints or pointers
are appreciated.

TIA,
Robert

 

[Pavel Vozenilek]

Now I still have the problem to distinguish between
stack and heap allocated objects

Check whether the "this" value is inside
stack range. It can be done portable and quickly.

/Pavel

 

[Walter Bright]

Check whether the "this" value is inside
stack range. It can be done portable and quickly.

It's easy to find the top of the stack, but I know of no portable way to
find the bottom of it. If I've missed something, please let me know!

 

[Pavel Vozenilek]

It's easy to find the top of the stack, but I know of no portable way to
find the bottom of it. If I've missed something, please let me know!

OK, I assumed garbage collection kicks in after main()
is entered and the current-top-of-stack at the moment
is stored as global variable.

/Pavel

 

[Walter Bright]

OK, I assumed garbage collection kicks in after main()
is entered and the current-top-of-stack at the moment
is stored as global variable.

That only partially works. There are the issues of the code executed before
main(), if you are running from a DLL then you have no idea where the stack
started out, and issues of the bottom of the stack in multithreaded code.

 

[Mike Wahler]

Check whether the "this" value is inside
stack range. It can be done portable and quickly.

This might be possible with some implementations,
but it's certainly not portable. (The language
makes no requirement that a 'stack' be used at
all).

-Mike

 

[Walter Bright]

This might be possible with some implementations,
but it's certainly not portable. (The language
makes no requirement that a 'stack' be used at
all).

True, but are there any implementations without a stack? Is there any point
to being concerned about them?

 

[Maxim Yegorushkin]

Check whether the "this" value is inside
stack range. It can be done portable and quickly.

What if the object is on another thread's stack? How do you find all
thread's stack address ranges?

 

[manu]

I think that there is no reason to use smart pointers and garbage
collecting for stack objects, because stack object exists only in block
in which it's declared. You may use some tricky methods, but that methods
are slow and potentially unsafe.

ptr<A> a_ptr;

void g(ptr<A> a) {
a_ptr = a;
}

void f() {
A a;
g(a);
}

void main() {
f();
a_ptr->some_func(); // crash!
}

 

[Robert Potthast]

Well, this is what I am actually trying to archive - to disable smart
pointers and GC for stack objects. Another possible solution would be
to manually "mark" the objects as heap allocated, after constructing
them. Maybe by using a custom allocation function - if C++ would give
the programmer the ability to call the constructor manually :/

 

[Robert Potthast]

OK, I have learned something: Keep It Simple, Stupid

class Object
{
/* this and that */
void addToHeapObjects()
{
/* add object to list of collectable objects */
}
};

And to make it even simpler:

template < class T >
T* heap(T* obj)
{
obj->addToHeapObjects();
return obj;
}


void main()
{
Object* heapObj = heap(new Object);
Object stackObj;
}

That is it. Perfect. Well at least I now have a clean GC and
smart-pointer interface