Email list hosting service & mailing list manager

(Previous discussion continued)
Re: when GC is permitted Felix Winkelmann (08 Jan 2004 08:58 UTC)

Re: when GC is permitted Felix Winkelmann 08 Jan 2004 08:58 UTC

Am 08 Jan 2004 03:34:45 -0500 hat Jim Blandy <xxxxxx@redhat.com> geschrieben:

>> I don't understand this. If the C code does not hold direct references
>> to the data (i.e. if you add an extra indirection), and if you access
>> the data only over a designated interface, GC can certainly run
>> whenever it wants, even during the execution of the C code. That's
>> the whole point of the abstraction exercise.
>
> I'm sorry.  I shouldn't be trying to write so late at night.

No worries.

>
> In code using this SRFI's interface, there are two classes of Scheme
> values:
>
> - Values that reside in GCPRO'd variables.
>
> - Values that reside anywhere else: in other variables,
>   compiler-generated temporaries, and so on.
>
> Values in the first class the GC can update when it relocates objects;
> those in the second class it cannot, because it can't find them.
> Values in the second class are unavoidable if you're actually
> operating on the values, since you can't control the code the compiler
> generates.

Absolutely. With the current SRFI-50 draft the problem is exactly
as you point out.

>
> By using the 'begin / end' pair of functions, you'd promise the
> SRFI-50 implementation that, outside such pairs, no values of the
> second class exist, and it is free to collect at any time.  When any
> thread is within such a pair, there exist object references the
> collector can't find or update, so collection has to wait until the
> thread reaches a "may gc" function.
>

I should have been more precise there: I understand the intention
behind the "critical section". My point is that with an extra-indirection
(as proposed by Tom or as used in JNI/minor - if I understand it right)
the second class values point to something opaque. The values inside
C locals and registers point to some "box" object that could easily be
registered
with the collector. Since the user can only access the data via
extraction forms, it's completely transparent.

This means that the problem would simply go away (IMHO), provided the
current draft proposal is changed in an appropriate manner.

cheers,
felix