Right! On Mon, Mar 31, 2008 at 1:09 AM, Aleksey Shipilev <[EMAIL PROTECTED]> 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 > <[EMAIL PROTECTED]> 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 > > > > <[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 > > >
-- With best regards, Alexei
