[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: |
Thu, 01 Nov 2007 00:04:53 -0700 |
User-agent: |
Gnus/5.1006 (Gnus v5.10.6) XEmacs/21.4 (Jumbo Shrimp, linux) |
R Karthick <karthick.ramachandran@gmail.com> writes:
> I havent thought about dynamically-linked executables yet. However I
> believe multi-threaded applications should work as the GC already
> supports it.
Supports it how?
In order to implement GC in multi-threaded environment, you must
be able to tell where all the thread stacks are. How are you going
to achieve that?
> 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.
So it assumes that .data+.bss starts at 'etext' and goes to 'end'.
> I am looking for the static start address for X86 similarly.
Linux 'ld' by default provides '_edata' and '_end', and will provide
'_etext' if you reference that symbol.
Cheers,
--
In order to understand recursion you must first understand recursion.
Remove /-nsp/ for email.
- Re: Static Memory Area for Garbage Collection,
Paul Pluzhnikov <=