Hi Robert,
I do not think that there is any general means of coercing the GC into
releasing store. There are a couple of specialised procedures
sys_grbg_list and sys_grgb_destpair that do this for lists. If it
is absolutely crucial for you application that you recycle store
then it is a fairly straightforward task to extend the Poplog GC with a
"manual" free. I wrote a library to do this ages and ages ago which
I will recreate if there is strong interest (since I left HP Labs
recently, much of my software is no longer accessible.)
However, it is important to realise that manual deallocation of store
jeopardises the integrity of the run-time system. It is even less safe
than in C because of the unpredictability of garbage collector that
typically "blows up" integrity faults into system failure.
So - at the risk of telling grannies not to suck eggs - do not bother
with it. The standard Poplog GC has ZERO COST for store that does
not survive a garbage collection! In other words, if you allocation a
tonne of ephemeral store you only pay for allocation and not deallocation
of that store. (OK, this is an oversimplification because the
frequency of GC is increased and the global cost has to be amortised over
each allocation. But the dynamic tuning of the Poplog GC reduces that
overhead to a constant fraction in short order. So the bottom line is
don't worry about it.)
This is NOT the same situation for incremental garbage collectors, such
as Java's, incidentally.
Furthermore, manual deallocation of store is not a straightforward
tradeoff. When store is deallocated incrementally, store allocation
ends up being more costly in order to take advantage of the newly
released store. Also store deallocation becomes more costly. And
the supposed performance improvements have to be weighed against the
very real possibility of programmer error destroying system integrity.
My position is that unless you really need to exclude GC's altogether
(which sometimes is the case) then stick with the Poplog GC. It is
a great piece of work and very practical.
Steve
|