harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Weldon Washburn" <weldon...@gmail.com>
Subject Re: [DRLVM][GC] ( Updated:HARMONY-1428) a submission of a mark-compaction GC
Date Thu, 21 Sep 2006 04:46:30 GMT
On 9/20/06, Xiao-Feng Li <xiaofeng.li@gmail.com> wrote:
> 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.

I am just guessing from the JIRA patches and the above comments that the
source tree should really look like:

  policy        <------------------- I added this to hold code that manages
the whole thing

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: harmony-dev-unsubscribe@incubator.apache.org
> For additional commands, e-mail: harmony-dev-help@incubator.apache.org

Weldon Washburn
Intel Middleware Products Division

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message