Laurynas Biveinis wrote: > 2006/5/3, Daniel Berlin <[EMAIL PROTECTED]>: > >> The number of *host* systems we support that don't have mmap is >> approaching 0, if it is not there already :) > > Uhm, at least DJGPP as a GCC host system is alive and does not support > mmap. But according to the following discussion, that's non-issue.
In the long run, I don't think we really want to be using garbage collection at all. The reason we started using it was that we had memory pools with ill-defined lifetimes, and stuff ended up in the wrong pool, and therefore got deallocated when it shouldn't. We added garbage collection as part of the transition to function-at-a-time mode in the C++ front end. My opinion is, in the long run, memory pools really are what we want -- just not as many as we used to have. In particular, we want one memory pool for global trees (global types, variables with static storage duration, functions), and one memory pool for the body of each function. References would be allowed from the body of each function to the global pool, but the other direction should be strictly limited to one pointer from each function to its body. (This allows you to read in/write out function bodies more easily.) The RTL for each function is generated when emitting code for the function, and is discarded after the function has been emitted as assembly code. Since we no longer do inlining on RTL, this RTL can be discarded immediately after use. To make this work, we have to be careful not to generate as much garbage as we presently do, as we'll needlessly waste space in these pools. Right now, we're using GC partly to compensate for things like using trees to represent strictly temporary data. All of the above should not in way be read as an argument against using the zone collector -- it's actually an argument in favor of improving the zone collector! It's going to take a while to do the bits above, and having better GC is going to help us until then. The great thing about the zone collector is that it's a step in the memory pool direction; it's zones can be the things I called pools. Whether we use GC on those pools, or turn the zones into obstacks, or whatever, is a separate step. -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
