harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mikhail Markov" <mikhail.a.mar...@gmail.com>
Subject Re: [classlib] H-3148 (OOM when using native memory which is out of GC-control) again
Date Tue, 15 May 2007 10:49:31 GMT
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.

Thanks,
Mikhail


-Mark.
>
>
>
>
>
>

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