harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alexei Fedotov" <alexei.fedo...@gmail.com>
Subject Re: [GSoC] Appliance for harmony-gc-4 "Unify the native memory management of Harmony DRLVM"
Date Sun, 30 Mar 2008 22:26:45 GMT
Right!

On Mon, Mar 31, 2008 at 1:09 AM, Aleksey Shipilev
<aleksey.shipilev@gmail.com> wrote:
> 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
>  >
>



-- 
With best regards,
Alexei

Mime
View raw message