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. 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]
