[racket-dev] Testing whether a procedure gets collected

This guide material (as opposed to language specification and
guarantees) looks pretty good to me. I'll edit and add the suggestion
of N allocations.

At Mon, 3 Dec 2012 10:39:09 -0600, Robby Findler wrote:
> Let me also say that I think it is important to give advice on how to
> test so I think we need to say something.
> 
> Robby
> 
> On Mon, Dec 3, 2012 at 10:37 AM, Robby Findler
> <robby at eecs.northwestern.edu> wrote:
> > 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:/co
> llects/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