[racket-dev] Testing whether a procedure gets collected

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:/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