Re: Garbage collection, part two...

From: Erick Gallesio <eg_at_unice.fr>
Date: Sun, 16 Apr 2000 23:03:34 +0200 (CEST)

Paul Anderson writes:

>
> Thank you for that suggestion. I had not known about
> volatile! The definitions for what it means are a little
> vague to say the least. I don't know if we can rely on
> all the compilers we might use to guarantee that
> it is obeyed.

I see that you are sceptical as well as me.
BTW, have you tried it on the platforms where you had the problem.
If it seems to correct the problem. I think that the solution
should be use volatile in STk code.

>
> > rrrr. finding other occurrences of this type of problem is
> > nontrivial. it can happen whenever you construct a scheme
> > object as a temporary holder for non-scheme objects.
>
> But only if you have taken a copy from the objects
> internals whose recovery by the GC would cause problems.
>
> It is hard for me to imagine cases where this might occur.
> I can think of plenty of nonsensical cases, such as:
>
> STk_makestring(CHARS(STk_makestring("one")));
>
> which doesn't make too much sense.
>

oops, I have perhaps things like that in the interpreter. For instance
the function expand-file-name produces a SCM object which is used by
the interpreter in some places for the string it produces . For
instance in do_load, there is a call
       full_name = CHARS(STk_internal_expand_file_name(full_name));
       ....
       and later a makestring of this string

After analyzing the code there is no allocation (in this particular
case) between the assignment and the string allocation so it should be
OK. But, as I said before, I didn't worry about these cases because I
was relying on the fact that the variable full_name was pointing the
string to prevent its collection. Assumption which seems to be no more
(always) true.


                -- Erick
Received on Sun Apr 16 2000 - 23:19:31 CEST