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 <ro...@eecs.northwestern.edu> wrote: > On Mon, Dec 3, 2012 at 7:47 AM, Matthew Flatt <mfl...@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 >>> <ro...@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 _________________________ Racket Developers list: http://lists.racket-lang.org/dev