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 <[EMAIL PROTECTED]>:
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 <[EMAIL PROTECTED]> wrote: > > On 5/17/07, Leo Li <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> wrote: > > > > > > On 5/15/07, 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-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
