harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Xiao-Feng Li" <xiaofeng...@gmail.com>
Subject Re: [DRLVM][GC] ( Updated:HARMONY-1428) a submission of a mark-compaction GC
Date Thu, 21 Sep 2006 00:16:11 GMT
On 9/21/06, Rana Dasgupta <rdasgupt@gmail.com> 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. :-)


Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org

View raw message