harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alexei Zakharov" <alexei.zakha...@gmail.com>
Subject Re: [classlib] H-3148 (OOM when using native memory which is out of GC-control) again
Date Wed, 23 May 2007 10:56:47 GMT
As far as I know DRLVM does not run on kernels older than 2.6 - see
old "building on Debian" thread for details [1]. So it looks like in
order to enable Harmony on pre2.6 (and on pre2.3) kernels we will need
to fix our code in several places anyway. And the
hysysinfo_is_system_physical_memory_low() function is not the most
complicated one.

This way, IMHO current patches for HARMONY-3148 look quite good. And
since the issue itself is rather critical IMO it is not a bad idea to
finally have it fixed and commit patches in their current state. If
later we decide to use other strategy for native memory deallocation
then we can always create another JIRA & patch and fix this.

BTW, Tim, if you don't have enough time for this (or do not interested
anymore)  I could take care of it.

[1] http://article.gmane.org/gmane.comp.java.harmony.devel/23167

Regards,

2007/5/18, Mikhail Markov <mikhail.a.markov@gmail.com>:
> I've reworked Leo's original patch and attached it to JIRA.
> Please review it.
>
> To complete the patch i'd like to discuss the proper use of sysinfo()
> procedure.
> As i mentioned, the format of the structure returned by sysinfo was changed
> since 2.3.23 kernel version for X86 by adding mem_unit field.
> We could just think that people are working with Linux-es with higher kernel
> versions and do nothing about this and could try to make a universal
> solution (currently the patch just utilizes mem_unit field thus this will
> not work on old Linux-es).
>
> This incompatibility is not new and here's, for example, one solution of
> "workarounding" the problem:
> http://lists.debian.org/debian-boot/2000/06/msg00387.html
>
> So, which way should we prefer?
>
> Thanks,
> Mikhail
>
> On 5/17/07, Andrew Zhang <zhanghuangzhu@gmail.com> wrote:
> >
> > On 5/17/07, Leo Li <liyilei1979@gmail.com> wrote:
> > >
> > > It might be too late when error occurs. Since GC is not in-place, when
> > > java
> > > runs out of memory, the GC itself may cannot work.
> >
> >
> >
> > Thanks Leo, now I see.
> >
> > And I'm also looking forward to seeing the ultimate fix by gc guys. :)
> >
> > On 5/17/07, Andrew Zhang <zhanghuangzhu@gmail.com> wrote:
> > > >
> > > > On 5/15/07, 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-3148as
> > > > > 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.
> > > >
> > > >
> > > > Hi,
> > > >
> > > > I'm not sure whether I understand the problem correctly, but is it
> > > > possible
> > > > that vm onlys invokes gc when it fails to allocate, instead of
> > checking
> > > > native memory every time before allocation which would may cause
> > > > performance
> > > > downgrade?
> > > >
> > > > (Mark mentioned that he'd refactored the patch if he had time:-) - i'm
> > > > ready
> > > > > to do this if he has no time.)
> > > > >
> > > > > Thanks,
> > > > > Mikhail


-- 
Alexei Zakharov,
Intel ESSD

Mime
View raw message