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