harmony-dev mailing list archives

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

I can say here that in DRLVM's GC v4.1 System.gc() is quite
lightweight and does exactly what you have said - detects unreachable
objects and push them into finalizer queue. :)

>
> 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.
>
> Regards,
> Tim

-- 
Ivan
Intel Enterprise Solutions Software Division

Mime
View raw message