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 Mon, 05 Feb 2007 11:16:17 GMT
On 2/5/07, Tim Ellison <t.p.ellison@gmail.com> wrote:
> Xiao-Feng Li wrote:
> > This might be crazy, but is it possible or reasonable to have a method
> > ByteBuffer.freeDirect()?
> No, we cannot extend the API.
> > It's a little big strange to me if API encourages this kind of
> > behavior that programmer grabs resources freely while relying on
> > certain unreliable behavior to release the resource.
> Had to smile at this, I'm sure a C programmer would say the same of the
> 'new' keyword -- then you GC-folk would be out of a job <g>

Hmm, this is different, Tim. The keyword is "unreliable". GC can and
must provide reliable memory management. And automatic memory
management is mandatory for type-safe programming languages. It is not
optional to use `free' or not as C does.

The native resources we are discussing here in Java are different from
Java managed heap. The only binding here is the association between a
Java object and its represented native resource. If there was not this
association, GC might not need to be involved at all. The problem is,
the implication of this association is not explicitly documented or

Since the direct ByteBuffer is with a piece of memory, it gives people
an impression that it's memory resource, must work as Java managed
heap. I am afraid this is inaccurate. Surely we can manage it in Java
heap to make its management reliable, then freeDirect is nonsense; but
I don't know if all the native resources can be managed reliably in
the similar way. And if we extend it to higher level resources, we
know explicit management is not a bad idea.

To manage it at higher level, probably we can accept the OOM
blissfully when allocDirect fails? This is not only for ByteBuffer
handling, but a pattern applicable to other native resources.

How do you think?


> Regards,
> Tim

View raw message