2007/2/2, Leo Li <[EMAIL PROTECTED]>:
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.
Sounds interesting. And if RI can prevent out-memory error but Harmony
fails to do that, I think we need to improve Harmony code.
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.)
I'm not sure, only a thought, if we can record all memory allocate
information in a table so that we can calculate when invoking free.
What's more, if we only focus on DirectByteBuffer, IMO, jni method
NewDirectByteBuffer/GetDirectBufferCapacity can easily take this task.
Notice these jni-methods are added in Java5 with DirectByteBuffer, I
think there may be some relation ship with DirectByteBuffer GC.
However, if we are looking forward to control all native memory, and
if we can get enough information about program memory use by system
call, I agree on this solution.
Some further questions remain, e.g, what can we do if memory is still
not big enough after GC?
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...
I wonder where is more suitable to put this native-memory-GC code, VM
or portlib. Due to the similar mechanism of original GC, will it make
sense if we put it into VM? And I think we can avoid adding a new
monitor, e.g, just call for GC in jni method, NewDirectByteBuffer
Waiting for some VM and GC experts :)
--
Leo Li
China Software Development Lab, IBM
--
Best Regards!
Jimmy, Jing Lv
China Software Development Lab, IBM
