help-gplusplus
[Top][All Lists]
Advanced

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

Re: Static Memory Area for Garbage Collection


From: R Karthick
Subject: Re: Static Memory Area for Garbage Collection
Date: Wed, 31 Oct 2007 00:46:55 -0700
User-agent: G2/1.0

Paul, Thanks a lot for the reply.

On Oct 31, 12:57 am, Paul Pluzhnikov <ppluzhnikov-...@charter.net>
wrote:
> R Karthick <karthick.ramachand...@gmail.com> 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!



reply via email to

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