Mailing-List: contact harmony-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: harmony-dev@incubator.apache.org
DomainKey-Status: good
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
        s=beta; d=gmail.com;
        h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references;
        b=k27Mf1u04SBTeV3GlV5A7BQDmVtcqQYB2LTrvuFQEV3nwntuyJEDpQsPgKK+DchehSbEnbOAyKj13KbwVWszuVm49gYZfljO+MR5iir0X9U3l+wVJwhLobfgm4t1qxzsLi6xagE7HqOEWOaksXLNYyLztJSMowFV67gTCT7Gadg=
Message-ID: <12385bbd0609141213v42762762gcac8d3ff48434be7@mail.gmail.com>
Date: Thu, 14 Sep 2006 23:13:30 +0400
From: "Ivan Volosyuk" <ivan.volosyuk@gmail.com>
To: harmony-dev@incubator.apache.org
Subject: Re: [General VM] GC strategy:how to garbage collect short-lived
 objects quickly.
In-Reply-To: <e66844de0609140231w4978ac0bh9de835154bcc8b64@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <e66844de0609132008r20d0492frf766f913b9f98997@mail.gmail.com>
	 <9623c9a50609132353k49ed4fei18b634bf1e074212@mail.gmail.com>
	 <e66844de0609140231w4978ac0bh9de835154bcc8b64@mail.gmail.com>

Well, common practise is to allocate most of the physical memory for
java heap and let the GC to deal with it. Different GC algorithms will
produce different pause times with different frequencies.

For your case, I think, it will be optimal to have old generation of
objects living untouched most of the GCs. The rest of the heap is for
young generation objects. GC can be made to occur more frequently if
we collect only part of the young generation space: the oldest chunk
of young generation at a time. There is a trade-off between portion of
heap collected and GC frequency, of cause.

Other techniques like the JIT's thread-local allocation can also help.
--
Ivan

On 9/14/06, Leo Li <liyilei1979@gmail.com> wrote:
> Dear Xiao-Feng:
>      Thank you for your advice.
>      I would like generational GC, but what I worry about whether it is
> preferrable to let GC start even if there is free memory existing.  Although
> the initiative gc fits in my case, I do not know the side-effect of frequent
> gc, for example, to pick out gc-able objects, to merge memory and to reset
> pointers to moved objects, especially on other cases. In my opinion, the
> strategy of current passive gc still has its market. Is it possible to let
> it configurable for application developers to choose the gc strategy?
>     Smatter compiler to allocate object on stack is really a good way since
> many a time an object is used as a local varaible. I think it is not so
> difficult for compiler to pick out local variables and what we need is just
> to let VM to allow space allocated on stack.:)
>     I am not quite familiar with JIT, but it will become a powerful
> supplement for static analysis.
>

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