harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Aleksey Shipilev" <aleksey.shipi...@gmail.com>
Subject Re: [GSoC] Appliance for harmony-gc-4 "Unify the native memory management of Harmony DRLVM"
Date Wed, 02 Apr 2008 10:26:11 GMT
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?

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
>

Mime
View raw message