Paul, Thanks a lot for the reply. On Oct 31, 12:57 am, Paul Pluzhnikov <[EMAIL PROTECTED]> wrote: > R Karthick <[EMAIL PROTECTED]> writes: > > I am in the process of designing a conservative garbage collector fo C++. > Designing or implementing?
I am modifying the mostly copying garbage collector(GC) by Bartlett (ftp://ftp.digital.com/pub/DEC/CCgc/13sep93.tar.Z) to implement the generations functionality using virtual memory. It is a school exercise. One of the first tasks include porting the compiler to X86 architecture. > 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? I havent thought about dynamically-linked executables yet. However I believe multi-threaded applications should work as the GC already supports it. > How do you know which pointers are pointing into the heap? > Have you already implemented malloc/sbrk replacement? This can be known by investigating the data in registers and static area. If the pointers point to the address which is within the bounds of the gc-heap, then it is suspected as a pointer and then will be considered as a base-set for the garbage collection. The malloc implementation is already done by Bartlett in the GC. > Unless you are programming under DOS, you don't care about *physical* > addresses, only virtual. I am sorry, I meant the virtual address. Infact in alpha architecture, for ZMAGIC files, 0x140000000 is considered as the lower bound for the static area that has be traversed for. I was assuming that I might be able to get away with a similar address for X86 architecture too. > 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(). Thanks a ton for the pointer, I shall look it up and try to find the static area. Just to add more detail, these are the static address pointers used by MIPS and SPARC respectively // MIPS #define STATIC_0 ((USINTP*)USRDATA) #define STATIC_1 (&end) // SPARC #define STATIC_0 ((unsigned*)(((((int)&etext)+NBPG-1)/NBPG)*NBPG)) #define STATIC_1 (&end) // NBPG comes from user.h with value as page size as default. I am looking for the static start address for X86 similarly. > > 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. I appreciate your suggestions. I shall look into it, once I implement the generations functionality. Thanks! _______________________________________________ help-gplusplus mailing list help-gplusplus@gnu.org http://lists.gnu.org/mailman/listinfo/help-gplusplus
