As far as I know, an object can be allocated in three different ways: - on the C heap, that is with malloc from the OS - on the stack - on the resource area I understand that objects allocated on the stack are never garbage collected, because they are on a stack and the garbage collector doesn't reclaim them. C heap objects seem to be garbage-collectable, at least the ones allocated on spaces (a space is a kind of a C heap object). What about resources? It seems that the ResourceArea memory is at first allocated from the heap, and then it is recycled whenever there is space for a new resource to be allocated. But are resources reclaimed by the garbage-collector? I am inclined to say that the GC only happens on objects allocated inside spaces. Can I do that? Contributions to the discussion are welcome. Regards, Douglas
------------------------------------------------------------------------
eGroups.com home: http://www.egroups.com/group/self-interest http://www.egroups.com - Simplifying group communications
Douglas Atique wrote:
As far as I know, an object can be allocated in three different ways:
- on the C heap, that is with malloc from the OS
- on the stack
- on the resource area
I understand that objects allocated on the stack are never garbage collected, because they are on a stack and the garbage collector doesn't
Actual Self objects are always allocated inside the object system, i.e. the new space or eden space of the Self world. Self objects are never allocated on the stack. The stack can only hold pointer to Self objects. The objects itself are always loacted elsewhere. The only entity that can be allocated from the stack are stack frames a.k.a. activation records for Self method execution or C language calls. These things as well as compiled code, processes and a lot of other administrative suff ("zone") are not Self objects.
The algorithms of the garbage collector is rather complex. He knows about how to traverse all those C++ data structures that makes up the Self system
but are not Self objects by themselves. The GC starts scanning for live objects at the list of active processes, propably the lobby, and some internal constants used by the compiler.
Nevertheless, most of the C++ data structures are acessible from the Self level. This connection is established through additional proxy objects (glue code). Look at processes or stack frames, for example. There is quite a lot of code necessary to "lift" the C++ objects up into the Self world.
The resource areas are a special mechanism to handle the allocation of temporary space in a FIFO fashion. They are compareable to the obstacks used by the Gnu CC.
Gordon.
------------------------------------------------------------------------
eGroups.com home: http://www.egroups.com/group/self-interest http://www.egroups.com - Simplifying group communications
The resource areas are a special mechanism to handle the allocation of temporary space in a FIFO fashion. They are compareable to the obstacks used by the Gnu CC.
I've never heard of this. What are obstacks ? Is this an internal lisp structure?
------------------------------------------------------------------------
eGroups.com home: http://www.egroups.com/group/self-interest http://www.egroups.com - Simplifying group communications
Dru Nelson wrote:
The resource areas are a special mechanism to handle the allocation of temporary space in a FIFO fashion. They are compareable to the obstacks used by the Gnu CC.
I've never heard of this. What are obstacks ? Is this an internal lisp structure?
No, this is nothing special to lisp. It is a method of handling memory allocation and deallocation. Inside the Self VM memory is managed in three different ways: 1) Non-Garbage-Collected Heaps. These are the CHeapObjects. These objects have to be deallocated explicitly. This is the method, memory is alloceted in C using malloc/free, and in C++ with new/delete. 2) Gargabe Collected Heaps. These objects do not have to be explicitly deallocated, and in Self these objects are stored in a special way with these tagged pointers. 3) Stacks. Objects are allocated in a FIFO fashion. This is the way, activation records are allocated the processor's run-time-stack, and this is the way the ResourceArea works. It provides some kind of a stack for allocating memory. It is used mainly for the Self compiler which is written in C++ and does not use the GCed heap. Stacks are quite handy for memory management while traversing syntax trees that require large amounts of dynamically allocated memory and lots of pointers but nevertheless have a quite predictive liveness behavior. Obstacks are only another implementation for this. They are also part of the Gnu libc where they are well documented.
Gordon.
------------------------------------------------------------------------
eGroups.com home: http://www.egroups.com/group/self-interest http://www.egroups.com - Simplifying group communications
gordon@cichon.de wrote:
Dru Nelson wrote:
The resource areas are a special mechanism to handle the allocation of temporary space in a FIFO fashion. They are compareable to the obstacks used by the Gnu CC.
I've never heard of this. What are obstacks ? Is this an internal lisp structure?
No, this is nothing special to lisp. It is a method of handling memory allocation and deallocation. Inside the Self VM memory is managed in three different ways:
- Non-Garbage-Collected Heaps. These are the CHeapObjects.
These objects have to be deallocated explicitly. This is the method, memory is alloceted in C using malloc/free, and in C++ with new/delete. 2) Gargabe Collected Heaps. These objects do not have to be explicitly deallocated, and in Self these objects are stored in a special way with these tagged pointers. 3) Stacks. Objects are allocated in a FIFO fashion. This is the way, activation records are allocated the processor's run-time-stack, and this is the way the ResourceArea works. It provides some kind of a stack for allocating memory. It is used mainly for the Self compiler which is written in C++ and does not use the GCed heap. Stacks are quite handy for memory management while traversing syntax trees that require large amounts of dynamically allocated memory and lots of pointers but nevertheless have a quite predictive liveness behavior. Obstacks are only another implementation for this. They are also part of the Gnu libc where they are well documented.
So, Gordon, is it only a matter of convenience? I mean, could all memory allocated from ResourceAreas be allocated from CHeaps, for example? For Self objects, on the other hand, I couldn't think of a better allocation scheme than the garbage-collected allocation, as there is no explicit mechanism in Self to destroy an object. Douglas
Gordon.
FreeShop is the #1 place for free and trial offers and great deals! Try something new and discover more ways to save! http://clickhere.egroups.com/click/381
eGroups.com home: http://www.egroups.com/group/self-interest http://www.egroups.com - Simplifying group communications
------------------------------------------------------------------------
eGroups.com home: http://www.egroups.com/group/self-interest http://www.egroups.com - Simplifying group communications
Douglas Atique wrote:
So, Gordon, is it only a matter of convenience? I mean, could all memory allocated from ResourceAreas be allocated from CHeaps, for example? For Self objects, on the other hand, I couldn't think of a better allocation scheme than the garbage-collected allocation, as there is no explicit mechanism in Self to destroy an object.
Yes, it is mostly a matter of convenience. The stack keeps additionally some notion where or when the memory is allocated. F. e. when traversing a syntax tree, an arbitrary amount of memory can be allocated at each node that can be easily deallocated without knowing what everything was allocated initially. This is the same what the garbage collector does, with one restriction: allocation
and deallocation must happen in a strict FIFO order.
A garbage collected heap is even more convenient than a stack because you don't have to worry about FIFO order any more. On the other side, it is also less efficient and causes a lot of overhead for the garbage collector. The Self compiler is written in C++ which does not have convenient garbage collection anyway. So it uses these ResourceAreas. That's one reason why the Self compiler is so fast.
I remember there is some research effort going on to let an optimizing compiler find situations where other allocation strategies can be applied other than the GCed heap. (Correct me if I'm wrong, I think it is Urs Hözle)
Gordon
------------------------------------------------------------------------
eGroups.com home: http://www.egroups.com/group/self-interest http://www.egroups.com - Simplifying group communications
Ups, I got something wrong in my last remarks about memory allocation:
I meant LIFO when I wrote about FIFO.
Gordon.
------------------------------------------------------------------------
eGroups.com home: http://www.egroups.com/group/self-interest http://www.egroups.com - Simplifying group communications
self-interest@lists.selflanguage.org
-
Douglas Atique -
Dru Nelson -
Gordon Cichon