[racket-dev] Testing whether a procedure gets collected

From: Robby Findler (robby at eecs.northwestern.edu)
Date: Mon Dec 3 11:37:42 EST 2012

On Mon, Dec 3, 2012 at 7:47 AM, Matthew Flatt <mflatt at cs.utah.edu> wrote:
> At Mon, 3 Dec 2012 08:04:15 -0500, Sam Tobin-Hochstadt wrote:
>> On Mon, Dec 3, 2012 at 7:54 AM, Robby Findler
>> <robby at eecs.northwestern.edu> wrote:
>> >
>> > I agree that when something is collected is a pretty intentional
>> > property but I think it is possible to say a little bit more since
>> > there is a pretty stable core idea there (namely that if something
>> > isn't reachable and you call collect-garbage you can be pretty sure
>> > it'll be gone -- this was not the case back in the boehm gc days).
>>
>> Do we really want to commit to this?  I agree that it's true for a
>> simple 2-generation GC, but something more complex like the Sun
>> garbage-first collector or Felix Klock's regional collector wouldn't
>> have this property, let alone something more complex like stack
>> allocation for non-escaping data.
>
> Yes, I think that a guarantee about individual objects with respect to
> `collect-garbage' is going to be too strong, because the garbage
> collector is meant to provide asymptotic guarantees instead of
> individual-object guarantees.
>
> I think tests like Neil's are best written to allocate N things and
> check that a good fraction of the N are released by a garbage
> collection. In Neil's specific example, I'd probably write the test to
> allocate 100 or 1000 of them, each with its own weak box, and make sure
> that at most of the weak boxes are empty after a forced collection.

Ah, whoops. I went and wrote a section to try to explain this
(assuming the current tech) before reading this message.

It is here:

http://git.racket-lang.org/plt/blob/280d924349c2af595af307d38ffdb24940ede80a:/collects/scribblings/guide/performance.scrbl#l417

My initial reaction to the above (perhaps colored by the fact that I
just wrote that section) is to still explain the current state, and to
revise this explanation when things improve (and, perhaps, explain in
the current version that things might improve in the future).

Or maybe does someone else want to try to edit my prose to take this
into account....?

Robby

Posted on the dev mailing list.