Re: Making GC aware of overall allocation?

[Michael Livshin <mlivshin at bigfoot dot com>]

Lars Arvestad <arve@nada.kth.se> writes:

> ML> /* maximum alignment on your system, the below is good for x86 */
> ML> #define SCM_MAX_ALIGN 4
> 
> I don't really mind small amounts of wasted space, but I don't
> understand what the SCM_MAX_ALIGN is necessary for. To protect against 
> size = 0 problems?

to protect against misalignment.  if your system's double alignment
is 8, you'll have problems adding hidden info in the first 4 bytes
of the block and then trying to access the double at ptr + 4 ;)

> My wishful thinking has been that the GC could look at the heap size
> once in a while (waving my hands here). If the heap was large and/or had
> grown more than what could be explained from Guile-side growth, a GC
> could be tried in order to release memory (yet more waving). I don't
> know Unix and Guile well enough to say wether this is possible or not.

it actually is possible on glibc 2.* linux systems (or so I'm told,
Greg Harvey surely knows more).  but portably -- nope.

> (1) I don't want my lib to be Guile
> dependent, and (2) that if I use Guile functions in my library code
> anyway, I could provide replacements (for e.g. scm_must_malloc) but
> that is a bad idea because the non-Guile programmers (and myself by
> mistake) will use the good old malloc, thus introducing bugs. My point
> is basically that a general library should be allowed to be unaware of 
> libguile.

maybe you could somehow abstract the allocation in your library, so
that it would be possible to use it with any allocation scheme (and
thus with any extension language)?  just handwaving, of couse, not
knowing the exact design etc.

> I do appreciate your and Miroslav's advice.

wait till all those 'merkins and Canadians pipe in ;)

> 	Lars

--mike

-- 
The journey of a thousand miles begins with an open parenthesis.
                                                           -- Rainer Joswig