Mailing-List: contact harmony-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: harmony-dev@incubator.apache.org
Received-SPF: pass (idunn.apache.osuosl.org: domain gmail.com designates
 66.249.92.171 as permitted sender)
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=eWqZc/qup9OO7XHJJyps/UOjsvSc81iXfDOWZcQAMb//1C3zvaTNQHQCBzudKCPgyZjhtES2QdVi/E1D3nwZcFyFud3fxQX02FAoaSYtDAQgGyQwn40jqVh1JABwakiQuGFR6uMSgddZ63aiO31nOwX0CGSAdt/QrseRiTW5k0g=
Message-ID: <9623c9a50609132353k49ed4fei18b634bf1e074212@mail.gmail.com>
Date: Thu, 14 Sep 2006 14:53:24 +0800
From: "Xiao-Feng Li" <xiaofeng.li@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: <e66844de0609132008r20d0492frf766f913b9f98997@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>

Hi, Dear Leo,

There are a couple of known approaches to collect short-lived objects.

The most common approach is generational GC, which is designed
specifically with the assumption that most objects die young in normal
applications. Simply put, the objects are arranged into spaces
according to their age, and the younger objects' spaces are collected
more frequently. GC pause time is improved since only part of the heap
is collected normally.

Another way is to let JIT to free objects whenever it sees
appropriate. The idea actually is letting JIT to insert object freeing
code sequence in the generated jitted code, so that the mutator can
free objects proactively. The "free-me" paper in this year's PLDI
exprimented this approach but showed this approach helps little with a
setting of generational GC.

Stack allocation may help the short-lived objects collection as well,
which requires escape analysis/detection (by compiler or hardware).
But my experience was that synchronization removal is the main benefit
from escape analysis, and stack allocation may not really help in our
evaluations.

Which approach is the best for your case may depend on the real
application behavior. Since generational GC is well-established for
this problem, we'd take this approach at first. GCv5 proposed is a
generational GC. We hope it can help to solve the problem you meet.
Stay tuned... :-)

Thanks,
xiaofeng

On 9/14/06, Leo Li <liyilei1979@gmail.com> wrote:
> Hi,all:
>    As we all know, java objects are allocated on heap instead of stack,
> thus there is a problem about how to garbage collect short-lived objects
> quickly.
>    In a recent real project I involved, a server built on java tries to
> send thousands of messages to client per second. A lot of short-lived
> messages is created as objects and discarded. (Although I can recycle these
> memory, there is still a byte array created during per call of nio read and
> write.) Since current GC strategy adopted by current RI starts to work only
> when the memory allocated approaching the limit of java heap, the work of GC
> is huge and will raise a wave on the server performance. Furthermore, after
> a long run, although I know GC will merge memory, the operating system
> reports there is memory fragment and in the worst case the OS will even
> report real memory is exhausted.
>    Of course it is possible to limit the java heap so as to force gc
> frequently as a workround, is it preferrable to collect short-lived objects
> quickly such as adopt aged-related object queues as one of the gc strategy?
>   What about the VMs here, drlvm or J9?
>
> Leo Li
> China Software Development Lab, IBM
>
>

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