Re: Static Memory Area for Garbage Collection

[Paul Pluzhnikov]

R Karthick <karthick.ramachandran@gmail.com> writes:

> I am in the process of designing a conservative garbage collector fo C++.

Designing or implementing?

As a school exercise, or re-inventing the wheel "for real"?
On which OS? Do you plan to support dynamically-linked
executables? What about multi-threaded ones?

> As one of the requirement of conservative garbage collection, I will
> have to scan through the static memory area and look for probable
> pointers into the heap.

How do you know which pointers are pointing into the heap?
Have you already implemented malloc/sbrk replacement?

> I am stuck in the implementation part, where I am not very sure on
> which physical address

Unless you are programming under DOS, you don't care about *physical*
addresses, only virtual.

> the static elements are stored for X86 machines. Is the address
> of the static area stored in some processor register? 

Which "the static area" are you talking about?

On Linux (likely your target OS), with dynamic linking, there is
at least one "static area" for each ELF image loaded into the
process, and there is no CPU register that points to any of them.

To find all such areas, on newer glibc versions you could use
dl_iterate_phdr().

An additional complication is that some programs obtain large memory
blocks from the OS via mmap(), and your GC would need to know about
them, or it will fail to be conservative.

Cheers,
-- 
In order to understand recursion you must first understand recursion.
Remove /-nsp/ for email.