harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Xiao-Feng Li" <xiaofeng...@gmail.com>
Subject Re: [VM]How to trigue GC while free native memory is low.
Date Sat, 03 Feb 2007 14:03:58 GMT
On 2/3/07, Ivan Volosyuk <ivan.volosyuk@gmail.com> wrote:
> On 2/3/07, LvJimmy´╝îJing <firepure@gmail.com> wrote:
> > 2007/2/2, Xiao-Feng Li <xiaofeng.li@gmail.com>:
> > > Thank you, Jimmy and Leo, for the clear explanations.
> > >
> > > I think temporarily you can put the System.gc() there to workaround
> > > this issue. Yes, this is only a workaround since we cannot rely on it
> > > without explicit guarantee in its semantics.
> > >
> > > To really solve this problem, we might need a careful design. Your
> > > proposed approach looks like a possible solution. Have you thought to
> > > solve the problem by using GC to manage the raw memory blocks? Without
> > > deep understanding of the problem, I have some wild idea below. Please
> > > see if it is reasonable or stupid. I will read the spec of ByteBuffer
> > > to get more understanding.
> > >
> > > Since what the ByeBuffer needs are starting address and capacity, it
> > > doesn't really care if this piece of memory is in Java heap or in
> > > native runtime memory ( I assume.) We probably can provide some
> > > special kind of virtual Java object that serves as raw memory block to
> > > nio. In this works, we need not monitor the native runtime memory
> > > usage.
> > >
> >
> > Ah, this solution sounds interesting to me, yes, if we malloc memory
> > in heap then we no longer need to monitor the native memory. But we
> > may need a kit of methods offer this heap-memory service:
> > 1) a function of malloc_in_heap()
> > 2) a function of free_heap_block()
> > 3) heap monitor should record this malloc/free action
> > 4) ...
> > However I do think this may be a good solution, and it still depends
> > on how easy can it be implemented. Note not only direct ByteBuffer
> > require this native memory usage.
> I like this idea. I think we can express it in more general way. We
> need native memory which is somehow related to java heap objects. When
> calling garbage collection there is high possibility that some of this
> memory will be freed. So here is my variant of this proposal:
> 1. a function gc_native_malloc() which allocates native memory and
> triggers GC on a certain threshold.
> 2. a fenction gc_native_free() which deallocates native memory and
> updates counter for the used space.
> This memory may be allocated in general native heap but it should be
> accounted by GC. It is not even required that it should be the GC who
> implements this functionality, just some code which will can call GC
> and able to allocate native memory.
> One drawback of this approach that we should know all the places where
> we have a relation between java heap object and native memory. Some
> custom native library may disobey this rule.

I've just studied ByteBuffer and MappedByteBuffer. If I understand
correctly, the latter one is similar to POSIX mmap, and it's a
subclass of ByteBuffer and uses a direct ByteBuffer. If it's
implemented in the way of mmap, we probably have no serious issue to
provide the required support in GC. The advantage to provide this
support in GC is, GC can decide when and how to start a collection.
And if the GC has some mechanism of reference counting, it can serve
the purpose even better.

The other point is, in the spec, the ByteBuffer can be created by
wrapping a Byte array. GC can provide this buffer as a direct buffer
if that's really wanted in certain scenario.


View raw message