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 <[EMAIL PROTECTED]> 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 > <[EMAIL PROTECTED]> 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
