harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Leo Li" <liyilei1...@gmail.com>
Subject Re: [classlib] H-3148 (OOM when using native memory which is out of GC-control) again
Date Thu, 17 May 2007 13:38:14 GMT
 Excuse me, actually I have just found there is a bug about the patch on
windows platform. That is why the testcase runs slow. I will modify it now.
 Sorry for the inconvenience.


On 5/17/07, Mikhail Markov <mikhail.a.markov@gmail.com> wrote:
>
> On 5/16/07, Andrew Zhang <zhanghuangzhu@gmail.com> wrote:
> >
> > On 5/15/07, Mikhail Markov <mikhail.a.markov@gmail.com> 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/
> >
>



-- 
Leo Li
China Software Development Lab, IBM

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message