harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Geir Magnusson Jr." <g...@pobox.com>
Subject Re: [VM]How to trigue GC while free native memory is low.
Date Sun, 04 Feb 2007 17:47:39 GMT

On Feb 4, 2007, at 8:41 AM, Gregory Shimansky wrote:

> Leo Li wrote:
>> On 2/4/07, Gregory Shimansky <gshimansky@gmail.com> wrote:
>>> I see no difference in the approach I've suggested already. If we  
>>> have
>>> to take care about all the native resource allocation inside of  
>>> classlib
>>> APIs, then there is no difference which code calls GC, be it
>>> gc_native_malloc, or the API native code like this:
>>> void *p = malloc(size);
>>> if (NULL == p)
>>> {
>>>   gc_force_gc();
>>>   p = malloc(size);
>>>   if (NULL == p)
>>>   {
>>>       jni_env->ThrowNew("java/lang/OutOfMemoryError");
>>>       return;
>>>   }
>>> }
>> But I am worried whether it is too late to force gc when memory  
>> allocation
>> fails. It will take some time to complete the release of  
>> resources, for
>> example, in finalizer() and this period of time is not  
>> predictable. Thus
>> the
>> malloc will still fails...:(
>> Futhermore, if we wait till memory allocation fails then to force  
>> gc, it
>> might be possible that more than one thread will encounter such a  
>> problem
>> and force gc. I am not sure whether it will lead to problem in vm.
>> So, I think it may be wiser to trigger a gc when free memory ratio is
>> low and before the failure in malloc actually occurs.
> Yes, I shouldn't have called the above code a "solution". I just  
> wanted
> to point to Ivan that there is no difference with taking care about
> memory allocation in GC code or in classlib code.
> You've found another problem in such approach, just running GC is not
> enough in this case because finalization may not be done in time to  
> free
> needed native resources.
> Speaking in DRLVM terms, the above code could also contain call to
> vm_run_pending_finalizers, but it is still not a solution for
> multithreaded case.

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?


View raw message