On 9/20/06, Weldon Washburn <[EMAIL PROTECTED]> wrote:
On 9/20/06, Xiao-Feng Li <[EMAIL PROTECTED]> wrote: > > > > On 9/21/06, Rana Dasgupta <[EMAIL PROTECTED]> wrote: > > > Very nice and fast Xiao Feng :-) I read through your first > submission > > and > > > had a couple of thoughts on how this could progress. Is it that to > hook > > up > > > the two seperately managed spaces, some of the policies ( eg., > promote > > > everything and have an upper limit on pause time ) need become > > implicit? > > > Or can we build in some structures for policy support later, eg., if > we > > want > > > to set aside a seperate creation space, and provide some concept of > age > > > ...maybe confine the copying implementation to a smaller aging > space.... > > > > Rana, good comments, since that's also what I was thinking when I > > built the directory structure. :-) > > > > Originally, the directory structure was: gc/src/[gen| nursery| mature| > > ...]. Then I thought I shouldn't build the generations arrangement > > into directory explicity. Rather, I created the directories according > > to the collector algorithms, like gc/src/[gen| trace_forwarding| > > mark_compaction | ...]. In this way, we have a couple of > > flexibilities. For example, the generations arrangement is orthorgonal > > to the collector algortihms, we can have one or more generations, and > > each generation has its choice of collector algorithm. When there is > > only one generation, the GC actually degenerates into a standalone > > single collector. > >I am just guessing from the JIRA patches and the above comments that the >source tree should really look like: >gc_v5 >common >gen >mark_compaction >policy <------------------- I added this to hold code that manages >the whole thing >trace_forward Sounds reasonable Weldon, thanks. I can't see the gc.xml either, so it may have stayed back on Xiao Feng's dev box :-)
