harmony-dev mailing list archives

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

I was being somewhat flippant xiaofeng by comparing the world in which
an explicit call to free() makes the resource available again, and the
automatic memory management that relies on GC at some indeterminate (by
the application) point in the future.

I'd be much happier if we could get to a model of continuous
profile-directed GC, rather than relying on allocation failures from
heap management.  But that's getting off-topic, and subject for
discussion over a beer!

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

There are so many external resources that could use this type of
management requirement that solving it only for a memory block probably
isn't the right answer.  Letting the malloc failure return to the class
libraries and allowing the class library code an attempt to recover
seems like the right answer.

The problem seems to be that the only tools we have in the class library
are System#gc() and System#runFinalization().  A full GC is likely too
heavyweight (we don't actually want the Java heap reclaiming, and
certainly don't need to incur compaction etc.), and draining the
finalizer queue doesn't ensure that the unreachable objects have been

We need the intermediate goal of 'enqueue finalizable objects', or in
the more general case, 'enqueue PhantomReferences'.  We can probably
even agree on creating a specific Java type for a
QuicklyDetectAsCollectablePhantomReference <g> if that helps, though I'm
not sure it will since it is the referent that is being considered.

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

The best we can do today is to call System.gc(), but it seems to be much
more than we actually want to do.


View raw message