[racket-dev] Testing whether a procedure gets collected

Thanks. Is the N suggestion a future-proofing kind of a thing, or is
there something today that could cause such a test to pass where a
single one might fail?

Robby

On Mon, Dec 3, 2012 at 10:42 AM, Matthew Flatt <mflatt at cs.utah.edu> wrote:
> 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