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 12:32:01 GMT
On 2/5/07, Tim Ellison <t.p.ellison@gmail.com> wrote:
> Geir Magnusson Jr. wrote:
> > On Feb 4, 2007, at 8:13 PM, Ivan Volosyuk wrote:
> >> On 2/4/07, Geir Magnusson Jr. <geir@pobox.com> wrote:
> >>> I'm getting confused on where people think that this problem needs to
> >>> be managed.  Am I misunderstanding that there should be some
> >>> awareness of this in the classlib or VM natives?  Seems like it can
> >>> be localized.
> >>>
> >>> I think that if whoever calls malloc() finds that the system is out
> >>> of memory, then it's too late.  I always thought that VMs manage
> >>> their conceptual native "heap" (all native resources consumed from
> >>> OS, including as Robin mentioned, filehandles) in a proactive manner,
> >>> like they do their java heap.  it's clear now that they don't.
> >>>
> >>> So when a caller to malloc() gets a null, it should simply throw an
> >>> OOM, assuming that the runtime environment did all it could to
> >>> prevent that.
> >>>
> >>> Can this be done through portlib, letting the VMs implementation of
> >>> it manage to whatever degree of sophistication is warranted?
> >>
> >> Actually, the portlib is the lowest layer we rely on. If we can have
> >> here a callback to VM's GC we can place the code in the portlib. I
> >> would also distinguish memory allocations which associated with java
> >> objects and that which doesn't. No need to account resources which
> >> will not be freed after garbage collection.
> >
> > That's true.  I was just thinking about keeping a clear idea of the
> > native resource usage, but that's actually a separate concept from
> > coupling to java objects and their lifecycle.
> I agree, and it is generally a good idea for the VM to track it's
> resource usage through the portlib so that apps can embed the VM with
> conditions that it uses no more than a given set of limits.  The class
> library can do the same thing in the core libraries, but it soon gets
> out of hand when you start interacting with more third-party libraries
> that are not telling you about their resource usage, or have limits of
> their own (such as GUI libraries).

I see here the main issue with this approach. Yes, third-party
libraries may not tell us about their resource usage.

Thus it is quite interesting to look at existing commercial VMs how
its deal with this situation. If such resources are not tracked by the
VM, then it may be possible for the library to account its resources
and call GC itself. But what should be done if we have thin java layer
on top of complicated third-party native library which provides very
complicated system using a lot of native resources, for example KDE
java bindings.

> >> As was mentioned we have different types of critical system resources.
> >> It makes sense to make a list of such resources:
> >>   malloc'ed memory
> >>   mmap'ed memory
> >>   shared memory (?)
> >>   file descriptors (files, sockets)
> >>   XWin / GDI resources (?)
> >>   more?
> >>
> >> What would be the accounting strategy for the resources? We could
> >> allocate them via some functions in this facility or we could only
> >> account them here and call GC using some buildin criteria.
> >
> > It's clear to me that accounting and "free when associated java object
> > is free" are two different notions...
> Yes.
> Regards,
> Tim

Intel Enterprise Solutions Software Division

View raw message