harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Rana Dasgupta" <rdasg...@gmail.com>
Subject Re: [VM]How to trigue GC while free native memory is low.
Date Mon, 05 Feb 2007 06:28:40 GMT
On 2/3/07, Xiao-Feng Li <xiaofeng.li@gmail.com> wrote:
> >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.

I agree. My contention is that management of most unmanaged resources come
under this category. C# for example, recommends a Dispose() design pattern
to release resources and the language ties it back to the finalizer. I
would suggest that we focus on solving the unmanaged memory release problem
which to me looks more critical because unlike threads, fd's etc, where
mappings are usually 1x1 between the unmanaged resource and the
corresponding java object, in this case, the api seems to allow tying very
large chunks of memory to the bytebuffer without an explicit release api. I
don't think that the JVM( except for specialized ones ) has the
responsibility to automatically account for and manage all types of
resources, but it is obliged to do automatic memory management as Xiao Feng
point out below.

>The case for direct ByteBuffer belongs to 1. I am afraid certain VM
> >support is necessary. The question is what and how.

I am not clear on what's the best approach. It seems that the most general
automatic solution would need to be based on reference counting, but that is
not a small task. I don't think that external monitoring threads etc. are
very neat. There is no way to get them perfectly right in spite of the non
trivial development needed to build them.  Xiao Feng suggested a feeDirect()
method which could be a good way, but one of the api people would need to
confirm if this addition is feasible.
  Is it feasible to add an option to the VM specifying a maxDirectMemory,
and for the api implemententaion to keep an account of how much has been
allocated and freed ? And on being requested for a new allocation, if it
thinks necessary, invoke on a gc private interface to force cleanup?

> xiaofeng
> > Regards,
> > Tim
> >
> >

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message