R Karthick <[EMAIL PROTECTED]> 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. _______________________________________________ help-gplusplus mailing list help-gplusplus@gnu.org http://lists.gnu.org/mailman/listinfo/help-gplusplus
