On 5/16/07, Andrew Zhang <[EMAIL PROTECTED]> wrote:
On 5/15/07, Mikhail Markov <[EMAIL PROTECTED]> wrote: > > Hi, all! > > I'd like to raise the problem with freeing native memory which is out of > GC > control again :-) (and https://issues.apache.org/jira/browse/HARMONY-3148as > one of it's demonstration). > (See the previous round at > http://thread.gmane.org/gmane.comp.java.harmony.devel/25768). > > Several people have added comments to the JIRA, but we need a general > decision on the following question: > > Do we accept the way which was introduced by Leo's patch in H-3148 (i.e. > check if there are enough native memory available before allocating new > one, > and call System.gc() (or System.runFinalization()) if necessary)? > > I'm +1 for this method. Hi, I'm not sure whether I understand the problem correctly, but is it possible that vm onlys invokes gc when it fails to allocate, instead of checking native memory every time before allocation which would may cause performance downgrade?
Well, i've tried both approaches on the test described in H-3148 (100 iterations of allocating 20Mb DirectByteBuffer-s) on my laptop with J9: 1) Pro-active memory monitoring (I've changed thresholds to 95% & 64M): the test works ok, I could do normal work in parallel 2) Recovering from OOM: the test works terribly slow, I couldn't do anything else as there was active disk swapping. On 42nd iteration the OOM was got, System.gc() was invoked and after that the memory allocation was retried. It was unsuccessfull and OOM was still got (perhaps there was not enough memory already even to proper run GC). So, even if second allocation in 2-nd method was successfull, i'd prefer the first one :-). Thanks, Mikhail (Mark mentioned that he'd refactored the patch if he had time:-) - i'm ready
> to do this if he has no time.) > > Thanks, > Mikhail > -- Best regards, Andrew Zhang http://zhanghuangzhu.blogspot.com/
