Return-Path: 
 <harmony-dev-return-11532-apmail-incubator-harmony-dev-archive=incubator.apache.org@incubator.apache.org>
Delivered-To: apmail-incubator-harmony-dev-archive@www.apache.org
Received: (qmail 14947 invoked from network); 7 Aug 2006 13:35:47 -0000
Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199)
  by minotaur.apache.org with SMTP; 7 Aug 2006 13:35:46 -0000
Received: (qmail 37127 invoked by uid 500); 7 Aug 2006 13:35:43 -0000
Delivered-To: apmail-incubator-harmony-dev-archive@incubator.apache.org
Received: (qmail 37074 invoked by uid 500); 7 Aug 2006 13:35:43 -0000
Mailing-List: contact harmony-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
List-Help: <mailto:harmony-dev-help@incubator.apache.org>
List-Unsubscribe: <mailto:harmony-dev-unsubscribe@incubator.apache.org>
List-Post: <mailto:harmony-dev@incubator.apache.org>
List-Id: <harmony-dev.incubator.apache.org>
Reply-To: harmony-dev@incubator.apache.org
Delivered-To: mailing list harmony-dev@incubator.apache.org
Received: (qmail 37059 invoked by uid 99); 7 Aug 2006 13:35:43 -0000
Received: from asf.osuosl.org (HELO asf.osuosl.org) (140.211.166.49)
    by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 07 Aug 2006 06:35:43 -0700
X-ASF-Spam-Status: No, hits=1.8 required=10.0
	tests=DATE_IN_PAST_48_96,RCVD_NUMERIC_HELO,SPF_HELO_PASS,SPF_PASS
X-Spam-Check-By: apache.org
Received-SPF: pass (asf.osuosl.org: domain of gcjhd-harmony-dev@m.gmane.org
 designates 80.91.229.2 as permitted sender)
Received: from [80.91.229.2] (HELO ciao.gmane.org) (80.91.229.2)
    by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 07 Aug 2006 06:35:41 -0700
Received: from root by ciao.gmane.org with local (Exim 4.43)
	id 1GA5G1-0001RR-Lg
	for harmony-dev@incubator.apache.org; Mon, 07 Aug 2006 15:35:01 +0200
Received: from 141.33.132.154 ([141.33.132.154])
        by main.gmane.org with esmtp (Gmexim 0.1 (Debian))
        id 1AlnuQ-0007hv-00
        for <harmony-dev@incubator.apache.org>;
 Mon, 07 Aug 2006 15:35:01 +0200
Received: from guilhem by 141.33.132.154 with local (Gmexim 0.1 (Debian))
        id 1AlnuQ-0007hv-00
        for <harmony-dev@incubator.apache.org>;
 Mon, 07 Aug 2006 15:35:01 +0200
X-Injected-Via-Gmane: http://gmane.org/
To: harmony-dev@incubator.apache.org
From: Guilhem Lavaux <guilhem@kaffe.org>
Subject: Re: [rant] Memory options in VM -- why is the default not 'unlimited'
Date: Fri, 4 Aug 2006 13:32:16 +0000 (UTC)
Lines: 32
Message-ID: <loom.20060804T152956-641@post.gmane.org>
References: 
 <509223F0BF55E74FA1247D17207E7A0C300CCD@orsmsx419.amr.corp.intel.com>
 <44CFB84F.5060801@sourcelabs.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Complaints-To: usenet@sea.gmane.org
X-Gmane-NNTP-Posting-Host: main.gmane.org
User-Agent: Loom/3.14 (http://gmane.org/)
X-Loom-IP: 141.33.132.154 (Mozilla/5.0 (X11; U; Linux i686; en-US;
 rv:1.7.10) Gecko/20050921 Firefox/1.0.7 Mandriva/1.0.6-16.4.20060mdk
 (2006.0))
Sender: news <news@sea.gmane.org>
X-Virus-Checked: Checked by ClamAV on apache.org
X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N

will pugh <willpugh <at> sourcelabs.com> writes:

> 
> Yes.  I apologize.  I stated it in the past because the issue was 
> resolved in the past.  More precise english probably would have been either:
> 
> How did Kaffe decide to deal with SoftReferences?
>   or
> How does Kaffe deal with SoftReferences?
> 
> Although, still interested in the answer to either of these questions.  
> Do SoftReferences basically become strong references without a limit?  
> Do they basically become WeakReferences?  or do they do something else?
> 
>     Thanks,
>     --Will

Hi,

Dalibor pointed me to this thread on harmony-dev. I can answer that kaffe does
not yet make a difference between weak references and soft references. They are
both cleared when the GC detects that the object is not anymore strongly
referenced. It generally happens when someone ask for more memory and the GC
tries to first clear the existing allocated memory. As the GC is not trying to
clear any weak references in the meanwhile this behaviour is justified. An
improvement would be to make a quick small clean each time an allocation is
requested. The problem is in the "small" because we do not have yet any way of
parsing the heap by small pieces probably some heuristic is needed there.

Regards,
Guilhem.



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