harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Andrey Yakushev" <andrey.yakus...@gmail.com>
Subject Re: [GSoC] Appliance for harmony-gc-4 "Unify the native memory management of Harmony DRLVM"
Date Mon, 31 Mar 2008 20:49:20 GMT
Aleksey,

I looked at your proposal and it seems to be the pretty complete list
of native memory management problems and good plan for starting of
them resolving.

I could only suggest more clear formulating the final goals of your
efforts. Some kind of success metric.

Would it be the reduction of used APIs, so it means more clear DRLVM
architecture? How many of them should be remained; and where is the
optimum? Does the freedom of API choice means better modularity?

Or it would be the resolving of known bugs. Which ones and how many?

Or performance improvement. What speedup is expected?

Or management improving. What could be improved precisely?


-- 
Thanks,
Andrey


On Mon, Mar 31, 2008 at 5: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.
>

Mime
View raw message