On Wed, Apr 2, 2008 at 6:26 PM, Aleksey Shipilev <[EMAIL PROTECTED]> wrote: > Thanks, Andrey, Xiao Feng! > Your comments are very valuable. > > 1. I had updated the wiki [1] with new version of proposal, emphasized > once more on goals. > > 2. Metric of success. I think that (a) projected boosts could not be > estimated right now, without working prototype, (b) bugs in memory > management are also covered by multiple wrappers and I expect some of > them will be exposed after moving to UMM, but still it's hard to > reveal without working prototype. So, I choose the "UMM is ready and > used in most of VM components" as good enough starting metric. What do > you think, Andrey? > > 3. GC and mmap. Though I had little experience with GC heap adjustment > mechanisms, why can't GC just use hyvmmap wrapper for mmap? If we will > cover the same interface as mmap do, then there should be no problems, > right? Moreover, it can eliminate cross-platform memory management > wrappers inside the GC and delegate this to UMM. Xiao Feng, what do > you think?
GC definitely should finally sit on a same layer as other parts. The problem is, it's not that easy as you may expect. To define the project within a controllable scope is good for you to accomplish. Thanks, xiaofeng > > Thanks, > Aleksey. > > [1] http://wiki.apache.org/general/AlekseyShipilev/GSoC2008/harmony-gc-4 > > > > On Tue, Apr 1, 2008 at 5:51 AM, Xiao-Feng Li <[EMAIL PROTECTED]> wrote: > > Hi, Aleksey S. very good proposal. It deserves Google support. :-) > > > > Two comments: > > 1. goal of the project. Your stated goals are related only to software > > engineering issues. I think it should also be related to performance > > issue and research issue. Specifically, a unified native MM can open > > up new opportunities such as large page for the entire system, data > > prefetch, JIT code caching management, Java directBuffer improvement, > > etc. > > 2. GC related. GC uses mmap for good reasons. It need to map certain > > pages or unmap them sometimes. This support is important for GC heap > > adjustment. It's common for GC to reserve certain space, then commit > > or decommit part of it. So basically GC has two set of memory uses: > > one is like malloc for its own runtime allocations, the other is like > > mmap for Java heap management. I would suggest we ignore the latter > > category at the beginning of the project. It's not an easy stuff until > > we have good understandings about the unified NMM. > > > > Thanks, > > xiaofeng > > > > On Mon, Mar 31, 2008 at 9: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. > > > > > > > > > > > -- > > http://xiao-feng.blogspot.com > > > -- http://xiao-feng.blogspot.com
