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 googlemail.com designates
 64.233.182.186 as permitted sender)
DomainKey-Status: good
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
        s=beta; d=googlemail.com;
        h=received:message-id:date:from:user-agent:mime-version:to:subject:references:in-reply-to:content-type:content-transfer-encoding;
        b=uqcZiIPv5KvhftboFHNLrnErTFEIIZDkz3M+Q9H/zfiD38FP/ZUilOBfGK8neVRsxmeAb8i3fLAbroxBbgfKNeUWUcVcgyIGDmLBr7QWjakcKJkrnjZi2AGBz7A9K2JZ2ECaP+I6xQF2EAEBr87FNPB8mid5FUtslZIkfnrEOIw=
Message-ID: <4509210E.6080907@googlemail.com>
Date: Thu, 14 Sep 2006 10:29:50 +0100
From: Oliver Deakin <oliver.deakin@googlemail.com>
User-Agent: Thunderbird 1.5.0.5 (Windows/20060719)
MIME-Version: 1.0
To: harmony-dev@incubator.apache.org
Subject: Re: [General VM] GC strategy:how to garbage collect short-lived
 objects
 quickly.
References: <e66844de0609132008r20d0492frf766f913b9f98997@mail.gmail.com>
	 <uvenrkoae.fsf@gmail.com>
 <e66844de0609140118y17dc94c5gf0c528559f938b6b@mail.gmail.com>
In-Reply-To: <e66844de0609140118y17dc94c5gf0c528559f938b6b@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Leo Li wrote:
> Hi,Egor:
>
> On 14 Sep 2006 12:30:49 +0700, Egor Pasko <egor.pasko@gmail.com> wrote:
>>
>> On the 0x1E4 day of Apache Harmony Leo Li 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 forcing gc by hand? does it help?
>
>
> Forcing gc by hand does work, but it is difficult for code to know 
> when to
> call gc.So I think it is better if VM can give some support since it 
> knows
> the global situation.:)

..and of course a manual gc() call does not necessarily result in a gc - 
there's
no guarantee - so even if it was the right time, you might not get it.

Regards,
Oliver

>
>
>>    What about the VMs here, drlvm or J9?
>>
>> In a DRLVM JIT (Jitrino.OPT) there is an escape analysis prototype. It
>> detects objects that can be allocated on stack (and, hence, on
>> registers). Currently, it is switched off by default, and, when
>> enabled, it just marks the objects that are not escaped. This info is
>> never used in Jitrino.OPT yet. Sometimes, escape analyzers help, but
>> not very much :)
>
>
> It will be great if JIT can help to allocation objects on stack.
>
> DRLVM GC gurus will say more ;)
>>
>> -- 
>> Egor Pasko, Intel Managed Runtime Division
>>
>>
>> ---------------------------------------------------------------------
>> 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
>>
>>
>
>

-- 
Oliver Deakin
IBM United Kingdom Limited


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