Return-Path: Delivered-To: apmail-incubator-harmony-dev-archive@www.apache.org Received: (qmail 58117 invoked from network); 19 Sep 2006 07:31:18 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur.apache.org with SMTP; 19 Sep 2006 07:31:18 -0000 Received: (qmail 62721 invoked by uid 500); 19 Sep 2006 07:31:03 -0000 Delivered-To: apmail-incubator-harmony-dev-archive@incubator.apache.org Received: (qmail 62669 invoked by uid 500); 19 Sep 2006 07:31:02 -0000 Mailing-List: contact harmony-dev-help@incubator.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: harmony-dev@incubator.apache.org Delivered-To: mailing list harmony-dev@incubator.apache.org Received: (qmail 62644 invoked by uid 99); 19 Sep 2006 07:31:02 -0000 Received: from idunn.apache.osuosl.org (HELO idunn.apache.osuosl.org) (140.211.166.84) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 19 Sep 2006 00:31:02 -0700 X-ASF-Spam-Status: No, hits=0.0 required=5.0 tests= Received: from ([130.56.64.71:12268] helo=messaging1.anu.edu.au) by idunn.apache.osuosl.org (ecelerity 2.1 r(10620)) with ESMTP id 8C/56-26148-0BC9F054 for ; Tue, 19 Sep 2006 00:30:58 -0700 Received: from [150.203.163.99] by messaging1.anu.edu.au (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTP id <0J5T0075YWVIR140@messaging1.anu.edu.au> for harmony-dev@incubator.apache.org; Tue, 19 Sep 2006 17:30:54 +1000 (EST) Date: Tue, 19 Sep 2006 17:31:24 +1000 From: Robin Garner Subject: Re: [General VM] GC strategy:how to garbage collect short-lived objects quickly. In-reply-to: To: harmony-dev@incubator.apache.org Message-id: <450F9CCC.9090709@anu.edu.au> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT References: <4509210E.6080907@googlemail.com> User-Agent: Thunderbird 1.5.0.5 (X11/20060728) X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N Egor Pasko wrote: > On the 0x1E4 day of Apache Harmony Oliver Deakin wrote: >>> 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 > > this one is easy :) make a gc2() magic in DRLVM and collect only young > objects on it.. to make code portable, implement gc2() as gc() for > other JVMs. Need to be patient until the generational GC. > > Can a hack like this be widely accepted in Java community? I think, yes. > I think GC research will soon make this unnecessary. For example the Sun VM has a concurrent collector for its mature space, so on a sufficiently lightly loaded system (or with a core to spare) you could eliminate most of the mature space collection pause time. In MMTk, there is a command line switch, -X:gc:fullHeapSystemGc, used to specify whether System.gc() causes a full heap collection. But no, I don't think this is something users should need to play with. cheers --------------------------------------------------------------------- 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