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

Re: when GC is permitted

This page is part of the web mail archives of SRFI 50 from before July 7th, 2015. The new archives for SRFI 50 contain all messages, not just those from before July 7th, 2015.

Am 08 Jan 2004 03:34:45 -0500 hat Jim Blandy <jimb@xxxxxxxxxx> 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 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

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.