harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Andrey Yakushev" <andrey.yakus...@gmail.com>
Subject Re: [GSoC] Appliance for harmony-gc-4 "Unify the native memory management of Harmony DRLVM"
Date Wed, 02 Apr 2008 11:15:08 GMT
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

Mime
View raw message