harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Hindess <mark.hind...@googlemail.com>
Subject Re: [classlib] H-3148 (OOM when using native memory which is out of GC-control) again
Date Tue, 15 May 2007 08:40:05 GMT

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.

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.

There is also an outstanding question from Alexey on the JIRA regarding
the different hardcoded policies that I think should be addressed.

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.)

-Mark.






Mime
View raw message