Mailing-List: contact dev-help@harmony.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@harmony.apache.org
Received-SPF: pass (herse.apache.org: domain of liyilei1979@gmail.com
 designates 66.249.82.231 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=beta;
        h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references;
        b=lTK00AtyoiDrq+tSk9pexznwYausTT9ce1QEaNOnrDz1wHOYANLoyT6M7gB2ap9kjKvz7tlM9i6xy/MfdpyJ6PzlojsJdZwQmQglx/p7Eechq0mL7mkk8Ki0bBWlGClGo/XiBgqTMpdsuhbLnjb3uKi3fStxi2kkD0TWv+mBZ2w=
Message-ID: <e66844de0702122051v474baedaue2227bec6e9b6ed0@mail.gmail.com>
Date: Tue, 13 Feb 2007 12:51:04 +0800
From: "Leo Li" <liyilei1979@gmail.com>
To: dev@harmony.apache.org
Subject: Re: [VM]take action for native memory control (was: Re: [VM]How to
 trigue GC while free native memory is low.)
In-Reply-To: <e66844de0702091649w433701d9qe43b58b460fa26d1@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_Part_94503_639545.1171342264354"
References: <5c8e69f0702090134j2e67b786v35e847e997d67dad@mail.gmail.com>
	 <51d555c70702090943i22445aeauabe78929f3a9c855@mail.gmail.com>
	 <e66844de0702091649w433701d9qe43b58b460fa26d1@mail.gmail.com>

------=_Part_94503_639545.1171342264354
Content-Type: text/plain; charset=ISO-2022-JP; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

Hi, all:
     I have put a patch for HARMONY-3148 to solve the problem.
     A utility class, org.apache.harmony.luni.platform.OSResourcesMonitor is
added, which wraps the native method to determine the system memory
status.(I am not sure whether it should be moved to portlib, since in luni,
there is just a native module shared by linux/unix. But the API I used here
is not posix compliant and I am not sure whether it works on other unix
platforms.)
     Before the allocation for the memory of a direct buffer, the system
memory status will be queried. If necessary, a System.gc will be invoked.
Although I am not sure of the System.gc() since the spec says it is not so
reliable, but actually it works as I expect. Seems GC normally will occur if
System.gc() is fired.:)
    The problem left is what is the threshold to decide a gc. After some
preliminary study, I found that it is related with VM and OS. Actually, the
difference is so large, for example, the version of j9 currently used on
windows requires 512M free space left, or else a memory allocation will
fail. But on linux, 64M is sufficient. DRLVM turns out to be similar
with the latter on both platforms. The threshold I currently used is a
little conservative to ensure no out-of-memory error of the issue
will reoccur. It is better if the VM can tell the minimum free memory
requirement.:)
    It is possible to treat with other native resources, at least memory
problem in the scope of classlib, like HARMONY-2530 about Deflator in this
way: Allocate the memory that needs to be released when the attached java
object is garbage collected, in a monitored manner and trigger gc if
necessary.


Good luck!
Leo.

On 2/10/07, Leo Li <liyilei1979@gmail.com> wrote:
>
>   Good!
>   I have just tried a memory resource monitor and it can be put as a part
> of portlib to detect the current usage of memory usage.
>   Maybe it can be the first step.:)
>
>  On 2/10/07, Rana Dasgupta <rdasgupt@gmail.com> wrote:
> >
> > The quick solution sounds great, thanks Jimmy. And opening the JIRA is
> > the
> > right thing to do.
> >
> > On 2/9/07, LvJimmy，Jing < firepure@gmail.com> wrote:
> > >
> > > Hi All,
> > >    I open a new thread for this topic as I'd like to take action for
> > > this. As RI behaves different from Harmony (it never throw that
> > > memory-out-error), it should be a bug of Harmony and we should fix it,
> > > so I open a JIRA, HARMONY-3148 to record this bug and action on it.
> > >    Up to now, I see two kinds of solutions:
> > >    One solution that is perfect to me is that modify current GC to
> > > handle this native memory , it may use Java heap as native memory, or
> > > try to control native memory as Java heap. But  IMHO, this may be a
> > > long way to go to reach this target, requiring long discussion and
> > > well-design for new GC(and VM).
> > >    Other poor but quick solution is detect native memory usage in
> > > classlib native code, and call System.gc() if necessary. This is a
> > > fast fix and at least solve part of the problem. A little study on
> > > this solution shows its feasibility and it may not require so much
> > > work as the perfect solution.
> > >    So I suggest patch our code with this quick solution in the while,
> > > and if GC gets ready for the perfect solution, we remove this patch.
> > > During this period, more discussion for the design are still welcomed.
> > >     Any ideas/suggestions/comments? Thanks.
> > >
> > > --
> > >
> > > Best Regards!
> > >
> > > Jimmy, Jing Lv
> > > China Software Development Lab, IBM
> > >
> >
>
>
>
> --
> Leo Li
> China Software Development Lab, IBM
>


-- 
Leo Li
China Software Development Lab, IBM

------=_Part_94503_639545.1171342264354--