[Top][All Lists]

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

Re: [Gcl-devel] Re: TMP_ALLOC in mpn_mul_n

From: Niels Möller
Subject: Re: [Gcl-devel] Re: TMP_ALLOC in mpn_mul_n
Date: 26 Aug 2002 09:26:55 +0200
User-agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2

Camm Maguire <address@hidden> writes:

> OK, then gcl will either have to step around, *or* rely on its
> traversal of the C stack to find pointers and relocate them.

To *relocate* pointers on the stack sounds really, really dangerous.

> Thanks!  One other observation as I study this -- Dr. Schelter appears
> to have explicitly added code ensuring that bignum pointers would be
> on the C stack, and therefore relocated by the gc, in code like the
> following: 
> /* we have to store the body of a u in a bignum object
>    so that the garbage collecter will move it and save
>    it, and then we can copy it back
> */   
> #define GCPROTECT(u) \
>  MP_INT * __u = MP(big_gcprotect); \
>  (__u)->_mp_d =   (u)->_mp_d; \
>  (__u)->_mp_alloc = (u)->_mp_alloc 
> #define GC_PROTECTED_SELF (__u)->_mp_d
> #define END_GCPROTECT (__u)->_mp_d = 0

To me, this code seems to indicate that the gc is *not* able to find
and relocate the u pointer (which is located either on the C stack or
in a register (which is probably saved on the stack by the time the gc
is run)). Instead, it copies the pointer into a global MP-variable
big_gcprotect, which is known to the gc apriori, and uses that. If gc
happens, then the pointer GC_PROTECTED_SELF will be apropriately
updated, but not u->_mp_d.

But if the gc can't do the right thing to pointers on the stack, then
calling almost any C-code that allocates memory can break. The only
simple solutions I see is

* setting some global flag while calling foreign C-code that may
  allocate memory. The gc should look at that flag, and avoid

* having the gc notice which blocks are referenced directly or
  indirectly from the stack or registers (typically locations that are
  only conservatively assumed to hold pointers), and make sure those
  blocks are *not* moved by the gc.

The issues of a relocating gc that examines the C stack (which seems
to require a conservatish approach) seems pretty hairy.


reply via email to

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