This is the mail archive of the guile@cygnus.com mailing list for the guile project.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
hjstein@bfr.co.il (Harvey J. Stein) writes: > Greg Harvey <Greg.Harvey@thezone.net> writes: > > > hjstein@bfr.co.il (Harvey J. Stein) writes, re: Maciej Stachowiak's > > suggestion of hobbit compiling startup files: > > > > > I *strongly* agree. It's not just startup time that's helped. It's > > > *also* run time in *2* different ways: > > > > > > 1. The compiled code itself runs faster. > > > 2. The compiled code isn't in the data space so GC doesn't have to > > > scan it. > > > > > > And, yes, a generational GC will help with 2, but a) it won't help > > > with 1 & b) when's *that* going to happen? > > > > > > > Hopefully soon, provided I stop forgetting really important things > > when figuring out how to implement it. I'm intending to put up notes > > on my web site soon on how I'm planning on going about it (I'd do it > > now, but I'm not completely sure yet ;). I've been a bit iffy about > > saying anything on the list, in case it prevents someone else who > > could get it much done much more quickly from working on it, but since > > that doesn't seem to have happened up until now, I'm doubting that > > there's too many people falling all over themselves to build a better > > guile gc ;) > > Have you checked out Wilson's survey of gc techniques? No, but I have listened to quite a few of his songs about surfing & cars, so I think I'm in pretty good shape (Brian Wilson, right?) I'm currently trying to figure out the most acceptable implementation(s) under the constraints of guile, rather than what a gen gc actually is :). Wilson doesn't deal too deeply with implementations outside of copying collectors in generational gc's (at least in the bigsurv paper, I'm intending to take a look at the previous paper later today, but I'm not expecting too much). Rather than enumerate them here, I'd prefer to wait a bit until I have some coherent notes ready for comment (this shouldn't take long, hopefully by the end of the weekend). The forgetting important things is referring to the fact that I came up with an initial quick cludge sort of approach to improving the gc while some time and thought was put into a real generational gc, that had the fundamental flaw of ignoring the fact that you can't change pointers from the stack (I would've remembered eventually, but I'm quite thankful to Jim for pointing that out, as well as trudging through some rambling emails on the topic :) Essentially, I'd like to have a thorough description of what's going to be involved with the implementation and some alternatives for dealing with the issues involved, a chance for other guile users to point out any fatal flaws in reasoning and possible improvements, as well as determining what space/time tradeoffs are considered acceptable. I figure that guile's been waiting long enough for a better gc, that a bit of extra time to make sure it's done right isn't too bad (and I want to avoid the 'I've got an idea, coding time!' approach, which could end up in a mess that isn't desirable for such a critical part of the system) -- Greg