harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alexey Varlamov" <alexey.v.varla...@gmail.com>
Subject Re: [classlib] H-3148 (OOM when using native memory which is out of GC-control) again
Date Tue, 15 May 2007 12:10:18 GMT
2007/5/15, Mikhail Markov <mikhail.a.markov@gmail.com>:
> On 5/15/07, Mark Hindess <mark.hindess@googlemail.com> wrote:
> >
> >
> > On 14 May 2007 at 20:22, "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-3148 as
> > > 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.  (Mark mentioned that he'd refactored the
> > > patch if he had time:-) - i'm ready to do this if he has no time.)
> >
> > I think I said (I certainly meant to) that I'm happy for this to go in
> > as it is.  I had some issues with the layout - I think the platform
> > specific code might fit better in hsysinfo.c - but this can be fixed
> > later.
>
>
> Sorry - i've incorrectly understood you.
>
> The other issue was that I couldn't get the regression test to fail.  I
> > think that was resolved - though it might help to attach fixed versions
> > of the fix and test patches.
>
>
> I will do this.
>
> There is also an outstanding question from Alexey on the JIRA regarding
> > the different hardcoded policies that I think should be addressed.
>
>
> Sure - this is the next step once we agree on the method.
>
> It might be worth considering whether it is possible to trigger GC when
> > a malloc fails and then retry the malloc.  (No platform specific code
> > would be needed in this case.)
>
>
> Perhaps, although in my opinion it's better to proactively monitor memory
> than recover from OOM.
> We could set different thresholds for different pieces of classlib.

Well, finding good thresholds might be not that simple, given a whole
variety of platforms and workloads. Recovery looks as much more
straightforward way, but probably less reliable/robust, e.g. when the
whole process is short on memory, any component is under the stress
and may fail.
So I'm inclined to the monitoring method, too.

--
Alexey

Mime
View raw message