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 Sun, 30 Mar 2008 21:09:02 GMT
Thanks, Alexei! I will try to address your concerns in next revision.

As for the style, I would prefer to have proposal technically
complete, to have the mutual expectations in place and keep in mind
what's we are really doing. Of course, I'm risking on criticizing the
exact ideas, but that's the point of this discussion, right? :)

Thanks again,
Aleksey.

On Sun, Mar 30, 2008 at 10:01 PM, Alexei Fedotov
<alexei.fedotov@gmail.com> wrote:
> Hello Alexei,
>  Good job. I like your enthusiasm, and a technical style of your paper.
>  But exposing technical details you put your ideas in risk of being
>  criticized, your know. I hope that your effort would be useful
>  regardless of few comments I have.
>
>  > Now DRLVM components use multiple wrappers for memory management: APR pools, STD_MALLOC,
PoolManager, MemoryManager, CRT malloc, VirtualAlloc and others.
>  > The primary goal of this project is to implement Unified Memory Manager (UMM)
>
>  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.
>
>  Thanks!
>
>
>  On Sun, Mar 30, 2008 at 6:53 PM, Aleksey Shipilev
>
> <aleksey.shipilev@gmail.com> wrote:
>  > Hi,
>  >
>  >  I had updated the proposal on GSoC site and made the copy on Apache Wiki [1].
>  >  I would appreciate anyone's comments and corrections, especially from mentors.
>  >
>  >  Thanks,
>  >  Aleksey.
>  >
>  >  [1] http://wiki.apache.org/general/AlekseyShipilev/GSoC2008/harmony-gc-4
>  >
>  >
>  >
>  >  On Thu, Mar 27, 2008 at 9:10 PM, Aleksey Shipilev
>  >  <aleksey.shipilev@gmail.com> wrote:
>  >  > Hi all, Xiao Feng, Andrey (Yakushev),
>  >  >
>  >  >  I want to apply for GSoC with the idea of unification of native memory
>  >  >  management of Harmony DRLVM. I had found some issues recently on
>  >  >  SerialBench that stresses the memory allocation subsystem and will be
>  >  >  glad to refactor NMM on DRLVM. I had filed the draft of application on
>  >  >  GSoC site, can you please review it?
>  >  >
>  >  >  Thanks,
>  >  >  Aleksey.
>  >  >
>  >
>
>
>
>  --
>  With best regards,
>  Alexei
>

Mime
View raw message