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 Btw, both the first and second submissions have this structure
already. The second submission has only gc/src/mark_compaction so that it can either be put under the same directory as the first submission or it can be played with standalone. The idea is to facilitate other developers' involvement. This design is only what I am planning, not sure if how difficult (or easy) it is to engineer. But I see no hard technical difficulty. Desirably, GCv4.1 can be put under this structure as well. The policy can then be a seperate issue from the collectors naturally. > I know that we made some assumptions upfront but I am not sure how well two > generations will work for the real apps( not Spec ) eg., where pause is > critical. We may want to keep policies orthogonal to this so that we are > flexible. With a suitably sized nursery, the pause time can be constrained in most collections when only nursery is collected. The live objects will be accumulated in mature space till a certain threshold is reached and then a mature collection is triggered. The pause time of mature collection is usually bigger which may give users a spike in response time. Parallel collection can reduce the latency, but the ultimate solution should be concurrent GC, which is an area I am also looking at but will only be the priority after parallel GCv5 is ready. Hopefully all these will happen soon. :-) Thanks, xiaofeng --------------------------------------------------------------------- Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
-- Weldon Washburn Intel Middleware Products Division
