2007/5/15, Mikhail Markov <[EMAIL PROTECTED]>:
On 5/15/07, Mark Hindess <[EMAIL PROTECTED]> wrote:
>
>
> On 14 May 2007 at 20:22, "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-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
