harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Andrew Zhang" <zhanghuang...@gmail.com>
Subject Re: [classlib] H-3148 (OOM when using native memory which is out of GC-control) again
Date Thu, 17 May 2007 14:24:45 GMT
On 5/17/07, Leo Li <liyilei1979@gmail.com> wrote:
>
> It might be too late when error occurs. Since GC is not in-place, when
> java
> runs out of memory, the GC itself may cannot work.



Thanks Leo, now I see.

And I'm also looking forward to seeing the ultimate fix by gc guys. :)

On 5/17/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?
> >
> > (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
>



-- 
Best regards,
Andrew Zhang

http://zhanghuangzhu.blogspot.com/

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