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 Fri, 02 Feb 2007 21:28:10 GMT
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.

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.

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

Mime
View raw message