harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "LvJimmy´╝îJing" <firep...@gmail.com>
Subject Re: [VM]How to trigue GC while free native memory is low.
Date Sat, 03 Feb 2007 03:19:33 GMT
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

Mime
View raw message