Re: Query regarding Parser stack

[Hans Aberg]

On 2004/10/30 13:03, Laurence Finston at address@hidden wrote:

>> There are a few more: In "registers", libraries, files, ... And these makes
>> a difference when implementing a GC: For example, the "registers", which are
>> used for temporaries (which may be allocated on the heap, despite the name),
>> should be registered as root objects to a tracing GC, but (other) free store
>> objects should not. The fact that one cannot distinguish between these in an
>> automated manner in C++, makes it very difficult to implement a GC in C++
>> (other than a reference count).
> 
> I suppose I should be more careful when I use the word "only".

Right.

> However, I believe the _C Annotated Reference Manual_ recommends not
> using the storage class specifier (correct term?) `register', giving
> the reason that a good optimizing compiler will generally make better
> decisions about what data should be stored in registers.

In is not directly to that question, but rather that the compiler may create
its own, anonymous data copies. In a tracing GC, one must know which type
each data object is, plus finding the root set in a convenient way. C/C++ do
not admit that. (In C, "register" is a hint to the compiler that this value
might be stored in a register. But modern CPU's have so sufficiently many
registers, in combination with modern skilled compilers which can figure out
how to do it on their own, that there is no point in using this term
anymore.)

> In addition, if such data is stored on the heap, then I doubt that
> it's useful to consider this to be a truly different form of memory
> allocation.

The point is that the objects will be behave differently in a GC relative to
how they where created, and in part, how one wants the memeory management to
be conducted.

> I don't understand what you mean by allocating memory in libraries.
> Won't any memory allocated by objects or functions in libraries be
> static, dynamic, or automatic, too?

Id not know so much about it. GC experts say that it is a complication. If
you want to have something to think about, a DLL will be like a file with
objects written into it. How should a GC handle it when the file is closed?

> I consider file i/o and memory allocation to be two different things.

Tradionally, they are treated like that. But one can store data in a file,
and a file is usually buffered in memory. So the differences are blurred by
that.

> For one thing, in order to read in data from a file, I must allocate
> static, dynamic, or automatic memory for an object in
> which to store it.

The problem is that a tracing GC starts at the root system to decide which
objects are still alive. Suppose some of your file objects point at object
in memory. How should you handle that? Killing off those memory objects when
the file closes will invalidate the file stored objects, and not doing it
will require keeping objects in memory for which there are no traceable
pointers at them. Such problems can probably be solved; I just want to point
out that it is a complication.

The best way to learn about those things is to try to write a tracing GC in
say C++. One will then see what fails.

  Hans Aberg