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 Tue, 01 Apr 2008 01:51:00 GMT
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