harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Xiao-Feng Li" <xiaofeng...@gmail.com>
Subject Re: [VM]How to trigue GC while free native memory is low.
Date Sun, 04 Feb 2007 04:38:09 GMT
On 2/4/07, Tim Ellison <t.p.ellison@gmail.com> 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.


> Regards,
> Tim

View raw message