Mailing-List: contact dev-help@harmony.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@harmony.apache.org
Received-SPF: pass (athena.apache.org: domain of andrey.yakushev@gmail.com
 designates 209.85.200.174 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=beta;
        h=message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references;
        b=paPU3TZdl4tLMNrJLMvLeKzsqNuLRXpB65/xE/BeLtDLA9bYGb9yN1wB4eBbv6jUvycitLW+EY9d9dEVC6oFB2ewQRuKvv1Jj7GebHQPx7BwMT3OGdZItcCtKXh4R+BqEIKMNy7K3ES6yf0ms3xba0CPVnaDPxSS/yh/p2Vxea8=
Message-ID: <3c7e1c080804020415v11227245h7fae411a1cc15c3b@mail.gmail.com>
Date: Wed, 2 Apr 2008 14:15:08 +0300
From: "Andrey Yakushev" <andrey.yakushev@gmail.com>
To: dev@harmony.apache.org
Subject: Re: [GSoC] Appliance for harmony-gc-4 "Unify the native memory
 management of Harmony DRLVM"
In-Reply-To: <4bebff790804020326n2184e868x83d237bae02c972b@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <4bebff790803271010t7912b1b7r77ebd2a5ad5c6e08@mail.gmail.com>
	 <4bebff790803300753qe3bbcfau64ad46928d77d266@mail.gmail.com>
	 <c30d70960803301101p513cfa0y8eb6e8b2a9ff1c59@mail.gmail.com>
	 <4bebff790803301409h11e6afe4k8d98e2fa9d2045ef@mail.gmail.com>
	 <c30d70960803301526q2cf043bdx735fecef19166152@mail.gmail.com>
	 <4bebff790803310652n5d7fc059m3726144deb739960@mail.gmail.com>
	 <9623c9a50803311851m6322263aj1b5a65364261ae75@mail.gmail.com>
	 <4bebff790804020326n2184e868x83d237bae02c972b@mail.gmail.com>

On 4/2/08, Aleksey Shipilev <aleksey.shipilev@gmail.com> wrote:
> Thanks, Andrey, Xiao Feng!
> Your comments are very valuable.
>
> 1. I had updated the wiki [1] with new version of proposal, emphasized
> once more on goals.
>
> 2. Metric of success. I think that (a) projected boosts could not be
> estimated right now, without working prototype, (b) bugs in memory
> management are also covered by multiple wrappers and I expect some of
> them will be exposed after moving to UMM, but still it's hard to
> reveal without working prototype. So, I choose the "UMM is ready and
> used in most of VM components" as good enough starting metric. What do
> you think, Andrey?

OK, let it would be the first step of investigation. But at least add
note that performance and memory footprint wouldn't be worse then now
on defined set of tests.

>
> 3. GC and mmap. Though I had little experience with GC heap adjustment
> mechanisms, why can't GC just use hyvmmap wrapper for mmap? If we will
> cover the same interface as mmap do, then there should be no problems,
> right? Moreover, it can eliminate cross-platform memory management
> wrappers inside the GC and delegate this to UMM. Xiao Feng, what do
> you think?
>
> Thanks,
> Aleksey.
>
> [1] http://wiki.apache.org/general/AlekseyShipilev/GSoC2008/harmony-gc-4
>
> On Tue, Apr 1, 2008 at 5:51 AM, Xiao-Feng Li <xiaofeng.li@gmail.com> wrote:
> > Hi, Aleksey S. very good proposal. It deserves Google support. :-)
> >
> >  Two comments:
> >  1. goal of the project. Your stated goals are related only to software
> >  engineering issues. I think it should also be related to performance
> >  issue and research issue. Specifically, a unified native MM can open
> >  up new opportunities such as large page for the entire system, data
> >  prefetch, JIT code caching management, Java directBuffer improvement,
> >  etc.
> >  2. GC related. GC uses mmap for good reasons. It need to map certain
> >  pages or unmap them sometimes. This support is important for GC heap
> >  adjustment. It's common for GC to reserve certain space, then commit
> >  or decommit part of it. So basically GC has two set of memory uses:
> >  one is like malloc for its own runtime allocations, the other is like
> >  mmap for Java heap management. I would suggest we ignore the latter
> >  category at the beginning of the project. It's not an easy stuff until
> >  we have good understandings about the unified NMM.
> >
> >  Thanks,
> >  xiaofeng
> >
> >  On Mon, Mar 31, 2008 at 9:52 PM, Aleksey Shipilev
> >
> > <aleksey.shipilev@gmail.com> wrote:
> >
> >
> > > Alexei,
> >  >
> >  >  I had addressed both of your issues in the updated proposal [1]:
> >  >   a. Added portlib pools as the candidate.
> >  >   b. Rephrased abstract a little, with emphasis on unifying.
> >  >   c. "Class-based service" added to improvements plan: service critical
> >  >  customers like exception handlers, etc.
> >  >   d. "Wrapping malloc/free" added to improvements plan.
> >  >
> >  >  I want to thank you with the idea (d) - that's the way of moving
> >  >  Classlib native code to UMM.
> >  >
> >  >  Xiao Feng, Andrey (Yakushev), can you please review?
> >  >
> >  >
> >  >  Thanks,
> >  >  Aleksey.
> >  >
> >  >  [1] http://wiki.apache.org/general/AlekseyShipilev/GSoC2008/harmony-gc-4
> >  >
> >  >
> >  > >  >  On Sun, Mar 30, 2008 at 10:01 PM, Alexei Fedotov
> >  >  >  >  <alexei.fedotov@gmail.com> wrote:
> >  >
> >  >
> >  > >  >  >  You forgot portlib pools. All this reads in a following way "We have
> >  >  >  >  >  seven memory subsystems, and I want to implement the eighth which
> >  >  >  >  >  would be the best." Ok, I put the same intention into STD_MALLOC three
> >  >  >  >  >  years ago. We attached APR for the same reason.You suggest adding UMM.
> >  >  >  >  >   Amount of systems continues to grow. Contrary, I would suggest having
> >  >  >  >  >  less memory management subsystems on completion of your project.
> >  >  >  >  >
> >  >  >  >  >  BTW, two important use cases are missed in your proposal. The native
> >  >  >  >  >  memory subsystem should continue serving critical customers such as
> >  >  >  >  >  lazy exception messages or finalizers even when it reported to others
> >  >  >  >  >  that the memory is exhausted. To prevent user's JNI code from
> >  >  >  >  >  exhausting memory we did not find a solution other than substitution
> >  >  >  >  >  of function table in C runtime library with our functions. Redirecting
> >  >  >  >  >  calls to our functions allows us plugging OS-level optimized memory
> >  >  >  >  >  managers and in this case we can continue using conventional malloc
> >  >  >  >  >  and free rather than inventing hymalloc.
> >  >
> >
> >
> >
> >  --
> >  http://xiao-feng.blogspot.com
> >
>


-- 
Thanks,
Andrey