Board index » delphi » Garbage Collection etc.

Garbage Collection etc.

(This time hopefully in the correct newsgroup ;-)

In the Delphi port of the ATerm library I've just implemented an garbage
collector. This was not a big deal, since garbage collection is a well
researched area. But I'm missing some background information, like on the
implementation of threads, for both thread variables and stacks. Any
contributions are welcome!

For an efficient mark-sweep garbage collector all memory objects of
(approximately) the same size should reside in dedicated blocks, or arrays of
evenly sized members. I remember a discussion on the implementation of user
defined memory allocation on objects, and this is how it can be done:

class function MyObjects.NewInstance: TObject; //override;
begin
  Result := InitInstance(MyAllocate(InstanceSize));
end;

procedure MyObjects.FreeInstance; //override;
begin
  MyDeallocate(Self, InstanceSize);
end;

MyAllocate returns an pointer to an appropriate memory block, i.e.
@MemBlock[first_free], and MyDeallocate returns that block back into the
freelist. In real life of course different blocks and freelists should be used
for any object size.

In the mark phase of the garbage collector first all objects in static (module
level) variables are marked, and then the stack is traversed for local object
references. Currently all static variables must be registered by appropriate
calls to ATprotect or ATprotectArray. Can somebody suggest an automation for
this task, perhaps based on RTTI or other unit specific information?

DoDi

 

Re:Garbage Collection etc.


"VBDis" <vb...@aol.com> skrev i melding
news:20020729180238.11623.00000022@mb-ck.aol.com...
[...]

Quote
> In the mark phase of the garbage collector first all objects in static
(module
> level) variables are marked, and then the stack is traversed for local
object
> references. Currently all static variables must be registered by
appropriate
> calls to ATprotect or ATprotectArray. Can somebody suggest an automation
for
> this task, perhaps based on RTTI or other unit specific information?

There is no information available on anything but published fields. But:
Your solution only affects the block of memory allocated to create the
instance, not for all subobjects, strings & dynamic arrays, etc.. This still
has to be done in the destructor, AFAIK. Where memory comes from doesn't
affect this.
--
Bj?rge S?ther
bjorge@hahaha_itte.no

Re:Garbage Collection etc.


Im Artikel <K%j19.4059$sR2.71...@news4.ulv.nextra.no>, "Bj?rge S?ther"
<bjorge@hahaha_itte.no> schreibt:

Quote
>Your solution only affects the block of memory allocated to create the
>instance, not for all subobjects, strings & dynamic arrays, etc.. This still
>has to be done in the destructor, AFAIK. Where memory comes from doesn't
>affect this.

IMO dynamic strings and arrays are handled automatically in every destructor,
and on exit of a subroutine. That's kind of the additional information which
I'm looking for.

Subobjects are supposed to be collectable, too, then they will also be
destroyed during garbage collection. Of course other objects must be destroyed
explicitly, as usual.

DoDi

Re:Garbage Collection etc.


Quote
> Im Artikel <K%j19.4059$sR2.71...@news4.ulv.nextra.no>, "Bj?rge S?ther"
> <bjorge@hahaha_itte.no> schreibt:

> >Your solution only affects the block of memory allocated to create the
> >instance, not for all subobjects, strings & dynamic arrays, etc.. This
still
> >has to be done in the destructor, AFAIK. Where memory comes from doesn't
> >affect this.

> IMO dynamic strings and arrays are handled automatically in every
destructor,
> and on exit of a subroutine. That's kind of the additional information
which
> I'm looking for.

I'm sorry, I believe I'm wrong about strings & dynamic arrays. Those are
cleaned up in TObject.FreeInstance, which is, I believe, called in code
*after* the .destroy; call (procedure _ClassDestroy).

Quote
> Subobjects are supposed to be collectable, too, then they will also be
> destroyed during garbage collection. Of course other objects must be
destroyed
> explicitly, as usual.

--
Bj?rge S?ther
bjorge@hahaha_itte.no
"VBDis" <vb...@aol.com> skrev i melding
news:20020801221357.19202.00000148@mb-mt.aol.com...

Other Threads