[schemepy] Ideas on dealing with the mzscheme's memory-moving GC?

[schemepy] Ideas on dealing with the mzscheme's memory-moving GC?

Tim Ansell mithro at mithis.com
Tue Jun 3 00:19:28 EDT 2008


On Tue, 2008-06-03 at 09:17 +0800, Chiyuan Zhang wrote:
> Hi,
> 
> I'm porting the mzscheme backend to 3m model. The GC of mzscheme is
> memory-moving. It may move object during garbage collecting. When
> programming in C/C++, some macros needed to record the local pointers
> so that the GC can update them when moving the objects:
> 
>   {
>     Scheme_Object *tmp1 = NULL, *tmp2 = NULL, *result;
>     MZ_GC_DECL_REG(2);
> 
>     MZ_GC_VAR_IN_REG(0, tmp1);
>     MZ_GC_VAR_IN_REG(1, tmp2);
>     MZ_GC_REG();
> 
>     tmp1 = scheme_make_pair(scheme_true, scheme_false);
>     tmp2 = scheme_make_pair(scheme_true, scheme_false);
>     result = scheme_make_pair(tmp1, tmp2);
> 
>     MZ_GC_UNREG();
> 
>     return result;
>   }
> 
> I don't think this is possible in Python with ctypes. Firstly, C
> macros are not available here. Secondly, even if you can managed to
> expand the macro in some way (manually, for example), you shouldn't
> force the user to write Python code in this way that every local
> variable need to be declared and registered first and call something
> like MZ_GC_UNREG before leaving a block.
>
> There's function scheme_dont_gc_ptr that can prevent object from
> collected, but it won't prevent the object from being moved. I'm also
> asking in the mzscheme mailing list to see whether there's such a
> function. However, I'm also asking: is there any way that we can
> cooperate with the memory-moving GC?

Firstly, the mzscheme memory model should never be exposed to the user.
It should all be hidden behind our API. It is our job to call the
correct methods so that mzscheme scheme knows when we have pointers to
the scheme objects.

I don't believe we will ever have "local variables" except in the
mzscheme.c helper file. Hence we won't have to worry about these macros.

I don't think the pointer's value changing from under ctype's feet will
actually be a problem. If it is then when we get back a pointer to a
mzscheme object will we will (probably) have to use the following
functions to create a useful "box" for us.
> 
> void** scheme_malloc_immobile_box(void* p)
>
> Allocates memory that is not garbage-collected and that does not move
> (even with 3m), but whose first word contains a pointer to a
> collectable object. The box is initialized with p, but the value can
> be changed at any time. An immobile box must be explicitly freed using
> scheme_free_immobile_box.
> 
> void scheme_free_immobile_box(void** b)
>
> Frees an immobile box allocated with scheme_malloc_immobile_box.

I'll be interested to see what the mzscheme list suggests is the correct
solution.

I think experimenting is going to be the best option.

Tim 'Mithro' Ansell



More information about the schemepy mailing list