Alastair Reid wrote:
[snip]
Region-based systems have the quite wonderful property that garbage is
disposed of promptly - you don't have to wait for the next GC for the
memory to be released. Which means that performGC becomes a nullop.
[snip]
This is not entirely true. Firstly, some
Do you want a stronger wording on what kind of garbage collection is
to be performed or do we want to keep it deliberately unspecified
(ie, leave it to the individual Haskell system)?
It'd be nice to say that it has to be a full GC - but I've no idea how
to specify that in a non-operational
Alastair wrote about performGC (snipped)
It'd be nice to say that it has to be a full GC - but I've no idea how
to specify that in a non-operational (i.e., implementation dependent)
way.
I certainly don't think you should constrain implementations to be able to perform
a full GC in any sense.
Alastair wrote about performGC (snipped)
It'd be nice to say that it has to be a full GC - but I've no idea
how to specify that in a non-operational (i.e., implementation
dependent) way.
George Russell [EMAIL PROTECTED] writes:
I certainly don't think you should constrain implementations to
Alastair Reid [EMAIL PROTECTED] wrote,
George Russell [EMAIL PROTECTED] writes:
Also there are probably hard-real-time GC algorithms (like Baker's
treadmill) or algorithms which are close to being hard-real-time
(like the train algorithm) where doing a full GC would be a major
pain.
I think the thing to do is add the existing performGC to the standard
(perhaps giving it an hs_ prefix in the process) and leave development
of an extended version of the function for when the GHC folk (or
anyone else with a generational collector) decide they want a
forcefulness argument. Come
