From dev-return-23893-apmail-harmony-dev-archive=harmony.apache.org@harmony.apache.org Sun Feb 04 04:38:40 2007
Return-Path:
Delivered-To: apmail-harmony-dev-archive@www.apache.org
Received: (qmail 30239 invoked from network); 4 Feb 2007 04:38:40 -0000
Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2)
by minotaur.apache.org with SMTP; 4 Feb 2007 04:38:40 -0000
Received: (qmail 5859 invoked by uid 500); 4 Feb 2007 04:38:40 -0000
Delivered-To: apmail-harmony-dev-archive@harmony.apache.org
Received: (qmail 5833 invoked by uid 500); 4 Feb 2007 04:38:40 -0000
Mailing-List: contact dev-help@harmony.apache.org; run by ezmlm
Precedence: bulk
List-Help:
List-Unsubscribe:
List-Post:
List-Id:
Reply-To: dev@harmony.apache.org
Delivered-To: mailing list dev@harmony.apache.org
Received: (qmail 5824 invoked by uid 99); 4 Feb 2007 04:38:40 -0000
Received: from herse.apache.org (HELO herse.apache.org) (140.211.11.133)
by apache.org (qpsmtpd/0.29) with ESMTP; Sat, 03 Feb 2007 20:38:40 -0800
X-ASF-Spam-Status: No, hits=-0.0 required=10.0
tests=SPF_PASS
X-Spam-Check-By: apache.org
Received-SPF: pass (herse.apache.org: domain of xiaofeng.li@gmail.com designates 66.249.92.170 as permitted sender)
Received: from [66.249.92.170] (HELO ug-out-1314.google.com) (66.249.92.170)
by apache.org (qpsmtpd/0.29) with ESMTP; Sat, 03 Feb 2007 20:38:31 -0800
Received: by ug-out-1314.google.com with SMTP id z36so930218uge
for ; Sat, 03 Feb 2007 20:38:10 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws;
d=gmail.com; s=beta;
h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references;
b=Qr65dwlURI2tttg1W5xBUY0KSpdkg6RjHw557ejrqhdcOnsQL9YCxjR0hNMyIGqBP9C1m633rpu6igVw3Wl73nXvXkhaJHa0QbkoJ41SSgirMd4IS3hrH7Q1TfYrVvT1joTrb3GhkYjT45EXhVdeZ/DHU1ftrn2wwzAohlTbGX4=
Received: by 10.78.204.7 with SMTP id b7mr931144hug.1170563890001;
Sat, 03 Feb 2007 20:38:10 -0800 (PST)
Received: by 10.78.154.18 with HTTP; Sat, 3 Feb 2007 20:38:09 -0800 (PST)
Message-ID: <9623c9a50702032038j49fda918g71f48b19500bffb7@mail.gmail.com>
Date: Sun, 4 Feb 2007 12:38:09 +0800
From: "Xiao-Feng Li"
To: dev@harmony.apache.org
Subject: Re: [VM]How to trigue GC while free native memory is low.
In-Reply-To: <45C50768.9050409@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References:
<9623c9a50702020105l7f070770m35594455bbfd6867@mail.gmail.com>
<9623c9a50702020244p4bba7163m801286d46851212c@mail.gmail.com>
<45C50768.9050409@gmail.com>
X-Virus-Checked: Checked by ClamAV on apache.org
On 2/4/07, Tim Ellison wrote:
> Xiao-Feng Li wrote:
> > Since what the ByeBuffer needs are starting address and capacity, it
> > doesn't really care if this piece of memory is in Java heap or in
> > native runtime memory ( I assume.) We probably can provide some
> > special kind of virtual Java object that serves as raw memory block to
> > nio. In this works, we need not monitor the native runtime memory
> > usage.
> >
> > This approach need certain contract between Java classes and GC about
> > the special kind of Java object. Probably we can write a layer of Java
> > class wrapper for raw memory allocation, which hides the contract from
> > other common classes.
>
> There is a requirement that the 'raw memory block' is pinned though,
> because addresses in that block may be passed into OS calls (and the
> point of a direct byte buffer is that the memory is not copied). I don't
> believe that is going to be a reasonable requirement for all VM
> implementations.
Tim, the pinned memory is required by the API spec. We have to support
it either in VM or API. (GC to support it doesn't necessarily mean to
have a pinned space in GC managed heap.) It's probably good to
distinct two different situations:
1. a native resource is associated with a Java object, and the
resource can only be released when the object is strongly unreachable.
In this case, the programmer who uses this class knows that a GC cycle
can help to release the unused resource. Then in his code, he probably
can directly invoke some VM interface to force a collection when the
resource is run out. We need certain VM support that serve the
purpose. Or the programmer just relies on the VM to provide sort of
automatic resource management.
2. a native resource is associated with a Java object, but managed by
the application; or the native resource is not associated with a Java
object at all (e.g., completely managed in native libraries). In this
case, the whole resource management burden is taken by the application
itself. There is no requirement to VM.
The case for direct ByteBuffer belongs to 1. I am afraid certain VM
support is necessary. The question is what and how.
Thanks,
xiaofeng
> Regards,
> Tim
>
>