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 <mfl...@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 >> <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:/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 _________________________ Racket Developers list: http://lists.racket-lang.org/dev