harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Xiao-Feng Li" <xiaofeng...@gmail.com>
Subject Re: [GSoC] Appliance for harmony-gc-4 "Unify the native memory management of Harmony DRLVM"
Date Wed, 02 Apr 2008 10:36:01 GMT
On Wed, Apr 2, 2008 at 6:26 PM, 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?
>
>  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?

GC definitely should finally sit on a same layer as other parts. The
problem is, it's not that easy as you may expect. To define the
project within a controllable scope is good for you to accomplish.

Thanks,
xiaofeng

>
>  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
>  >
>



-- 
http://xiao-feng.blogspot.com

Mime
View raw message