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. Thanks, Mikhail -Mark.
