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 10:18:42 GMT
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).

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



View raw message