[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Date: Mon, 21 Jul 86 09:26 ???
From: Jim Hassett <HASSETT%sperry-csd.csnet@CSNET-RELAY.ARPA>
Your date field ended in ???, which our mail header parser decided not
The discussion concerning (GC) suggests that a major use would be to
trigger garbage collection so that delays could be avoided during some
subsequent processing, such as benchmarks or real-time operations. It
seems a bit devious to invoke garbage collection for the purpose of
preventing it, so perhaps a more direct approach to this application could
without-gc-delay form [Macro]
Evaluates form and returns what form returns, but prevents (as far as
is reasonable for the implementation) delays due to garbage collection.
It could be left up to the implementation to decide whether garbage collection
should be done before evaluating the form. Obviously, it is possible that
some forms which could otherwise be handled might exhaust available memory
when processed in this manner, unless the implementation can provide for
doing garbage collection if it can be seen to be necessary.
Does this make sense over a reasonably broad range of implementations?
I think so.
Is it sufficiently useful to be included in the language?
Quite possibly. This is the best thing I've seen from this discussion
so far. You also raise some of the right issues. As an example to some
of the things this would do in the Symbolics implementation, it would
prevent the GC from starting during execution, and cause "scavenging
during cons" to be turned off. As you say, the implementation may do
(or finish) a GC before entering the form. In copying garbage
collectors, you could have a "delay" by referencing an object in
oldspace and needing to transport it.
It may also be a reasonable restriction/warning that implementations
must be careful to avoid spending too much time within the form, since
it may inhibit all GC activity, and you could therefore run out of room.