[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Static Memory Area for Garbage Collection

From: Paul Pluzhnikov
Subject: Re: Static Memory Area for Garbage Collection
Date: Tue, 30 Oct 2007 21:57:52 -0700
User-agent: Gnus/5.1006 (Gnus v5.10.6) XEmacs/21.4 (Jumbo Shrimp, linux)

R Karthick <> 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

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.

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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]