Mailing-List: contact dev-help@harmony.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@harmony.apache.org
Received-SPF: pass (herse.apache.org: domain of firepure@gmail.com designates
 64.233.182.186 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=beta;
        h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references;
        b=M4g762rPIjZv12u8MocaNpU1z7ADNmEmwmJ0KPBSzvzkB0y8vHi+u86G+kFxY6uu+nYlwBQSFK2VTHcCTxEFzOurAU5jZXReVGUlv/PiIT0VzslMCtW6C5OL8qHMKLlC2dgTcsCsQiSSX6mh8DDSrYijs4yGlqy6UEts1d2p2Qo=
Message-ID: <5c8e69f0702021919t1397e66chca393638ce4c32c8@mail.gmail.com>
Date: Sat, 3 Feb 2007 11:19:33 +0800
From: "=?GB2312?B?THZKaW1teaOsSmluZw==?=" <firepure@gmail.com>
To: dev@harmony.apache.org
Subject: Re: [VM]How to trigue GC while free native memory is low.
In-Reply-To: <12385bbd0702021328p4fbe2f08wf0bd15827851b340@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <e66844de0702012308r619847e4wc66f692d7ac67a8b@mail.gmail.com>
	 <9623c9a50702020105l7f070770m35594455bbfd6867@mail.gmail.com>
	 <e66844de0702020201o1f5a0645ifbc64b7ede8d052c@mail.gmail.com>
	 <epveor$c57$1@sea.gmane.org>
	 <12385bbd0702021328p4fbe2f08wf0bd15827851b340@mail.gmail.com>

2007/2/3, Ivan Volosyuk <ivan.volosyuk@gmail.com>:
> Let me summarize:
>
> Sometimes we have small java heap objects which relates to much bigger
> native memory chunks. In some cases this memory may exceed limits and
> VM will crash. Calling GC from the other side will make this memory
> free. There are quite a few place in VM and classlib which uses such
> design pattern. In order to deal with this correctly some general
> solution required.
>
> We can do the following:
>
> 1. We can monitor virtual memory of running process via some hooks
> from operating system or use a special thread to do so.
> Actually I have already experimented with this for a while and it
> become clear to me that it cannot be use reliably. We can detect
> increase in virtual memory consumption when process virtual memory
> increases, if running GC some of memory will be freed but virtual
> memory consumption will not necessary decrease. Filling in the hidden
> from use freed memory is not visible and then will see next phase on
> virtual memory increase. After a few cycles we will end up with
> process crash.
>

We may not need to monitor memory, a simple thought
// try to malloc a block of memory
void * somepointer = malloc(memsize);
if (0 == somepointer){
     call system gc
}
// try again, if failed, throw out-of-memory error
...

> 2. We can use custom native memory allocator which override system one
> for all memory allocations or just for the ones originating from
> VM/classlib.
> We can have much more control on memory consumption then. Currently
> I'm investigating this possibility. It require careful design in order
> to make it work reliable, predictable and efficient. If somebody have
> fresh ideas or can give links for corresponding articles we could
> gather its here and develop a general solution.
>

It is something like java GC itself right? Then we have a native GC.
I'm thinking of it as well,
but if we have to control a memory pool, use original GC, use java
heap may be a better way?

> 3... ?
>
> --
> Ivan
> Intel Enterprise Solutions Software Division
>
> On 2/2/07, Gregory Shimansky <gshimansky@gmail.com> wrote:
> > Leo Li wrote:
> > > Hi, Xiao-Feng:
> > >     Excuse me if I am confusing you.
> > >     The direct byte buffer holds a block of native memory space used in nio
> > > operation. The native byte buffer will be freed through the byte buffer is
> > > gc collected and added to ReferenceQueue monitored by MemorySpy series
> > > classes.
> > >     But the gc will not be triggered if the java heap is still empty. Here
> > > is an example: I allocate a large block of native memory for a byte buffer
> > > while the byte buffer itself is quite small. Thus quickly native heap is
> > > depleted while VM still does not think gc is needed since java heap has a
> > > lot of free memory.
> > >
> > >
> > > import java.nio.*;
> > > public class Test {
> > >    public static void main(String[] args) throws Exception {
> > >        for(int i = 0;i<1000;i++)
> > >        {
> > >            ByteBuffer byteBuffer = ByteBuffer.allocateDirect(10240000);
> > >            //System.gc();
> > >        }
> > >   }
> > > }
> > > RI runs well but Harmony will soon throw OutOfMemory exception.
> > > But if remove the comment before System.gc(), Harmony will become ok.
> > > So my point is that we need a mechanism to notify VM to start gc if we have
> > > no more native memory because sometimes problem will be solved if gc is
> > > fired. Of cause we cannot avoid a  user always malloc space but never free
> > > them.:)
> >
> > ByteBuffer is not the only one class which has associated native
> > resources that are freed when Java object is collected. And it is not
> > the only class which may run out of such native resources before garbage
> > collection is needed for Java heap. You can see a similar problem
> > described in HARMONY-1831 where GZIPOutputStream allocates associated
> > native memory in ZLIB which ends up before GC collects unused objects.
> >
> > Other types of native resources could be handles and other OS specific
> > stuff. I am not sure, but it is probably easier for a particular type of
> > Java API class to realize that there are no more specific native
> > resources (like when ZLIB returns Z_MEM_ERROR in HARMONY-1831) left for
> > it and trigger GC unconditionally, then retry allocating resource again.
> >
> > > On 2/2/07, Xiao-Feng Li <xiaofeng.li@gmail.com> wrote:
> > >>
> > >> Leo, I can't fully understand your problem and proposal. I am working
> > >> in DRLVM GC component, I want to understand how GC can tackle the
> > >> issue you meet.
> > >>
> > >> You said the native memory is allocated (probably with malloc) for
> > >> byte buffer. I wonder how the process goes. I assume it's in native
> > >> code. Then you use malloc to allocate a block of memory, and put some
> > >> Java object (byte buffer) into it? Is this what you do? I wonder how
> > >> do you manipulate Java object placement in native code; and if the
> > >> native memory block is out of Java heap, do you expect GC to manage
> > >> it?
> > >>
> > >> You said when GC reclaims those byte buffer object, the native memory
> > >> block can be freed in native code. How do you know if an object is
> > >> reclaimed by GC or not?
> > >>
> > >> Thanks,
> > >> xiaofeng
> > >>
> > >> On 2/2/07, Leo Li < liyilei1979@gmail.com> wrote:
> > >> > Hi, all:
> > >> >     After applying patch3073, I added the support for direct byte
> > >> buffer
> > >> in
> > >> > nio module as spec requires. But now here exists a problem: The native
> > >> > memory allocated to the byte buffer can be released when gc releases
> > >> the
> > >> > byte buffer object, however, if the native heap is full while java heap
> > >> > still has space, gc will not be triggered.
> > >> >     It seems that RI will start gc before native memory heap is
> > >> depleted
> > >> and
> > >> > thus prevents out-of-memory error.
> > >> >
> > >> >    Then our work focuses on:
> > >> >    1. When gc is required.
> > >> >    2. Trigger a gc.
> > >> >    The first one requires that we get support from operating system,
> > >> since
> > >> > the memory allocated in the native code, for example by malloc, is out
> > >> of
> > >> > the control of java VM.( I have ever thought of counting the used
> > >> memory
> > >> in
> > >> > hymemory_allocate, but the plan fails since hymemory_free will not
> > >> report
> > >> > how much space is released.)
> > >> >    The second one needs the help from VM. System.gc() is not so
> > >> reliable
> > >> as
> > >> > spec says, so it is necessary to have a internal channel to notify
> > >> VM to
> > >> > start gc.
> > >> >
> > >> >     One solution, I think, is to let a monitor thread in VM to check
> > >> whether
> > >> > OS physical memory is low. For example, the
> > >> QueryMemoryResourceNotification
> > >> > of win32 API is a candidate. Although the interrupt model is more
> > >> effective:
> > >> > win32 SDK provides a CreateMemoryResourceNotification to get a handler
> > >> on
> > >> > which the monitor thread can wait, maybe on other platforms, OS does
> > >> not
> > >> > supply such a convenience. So the monitor thread in the VM might
> > >> have to
> > >>
> > >> > check the OS resource once for a while and if necessary the monitor
> > >> thread
> > >> > will call a GC.
> > >> >
> > >> >    My suggestion is first to add some function to monitor memory in
> > >> portlib,
> > >> > since it is highly related to platforms and in portlib there has been
> > >> > some useful tools.(Thanks Mark to point out that.) On the other
> > >> hand, we
> > >> can
> > >> > negotiate a channel to trigger gc in VM. Actually I am not an expert on
> > >> VM
> > >> > since I am not sure whether there has been some monitor thread and the
> > >> load
> > >> > on performance if such a monitor thread is added to the VM...
> > >> >
> > >> >
> > >> > --
> > >> > Leo Li
> > >> > China Software Development Lab, IBM
> > >> >
> > >> >
> > >>
> > >
> > >
> > >
> >
> >
> > --
> > Gregory
> >
> >
>


-- 

Best Regards!

Jimmy, Jing Lv
China Software Development Lab, IBM