Hello all, Aleksey, I have seen your proposal on UMM for GSoC. It is a very good idea to refine the native memory management in DRLVM. I am also interesed in this topic. How is it going now?
Thanks, Ligang On 4/3/08, Xiao-Feng Li <[EMAIL PROTECTED]> wrote: > > On Thu, Apr 3, 2008 at 9:41 PM, Andrey Yakushev > <[EMAIL PROTECTED]> wrote: > > You want to have big gap from the beginning. :) > > I think its OK, but I suggest removing SPECjbb as not too > > representative for native memory usage. > > > > Agreed with Yakushev. > I personally think that both footprint and performance should be > better finally. > > As a start point, Shipilev's targets are ok anyway. > > Thanks, > xiaofeng > > > On 4/2/08, Aleksey Shipilev <[EMAIL PROTECTED]> wrote: > > > > > > > On Wed, Apr 2, 2008 at 3:15 PM, Andrey Yakushev > > > <[EMAIL PROTECTED]> wrote: > > > > OK, let it would be the first step of investigation. But at least > add > > > > note that performance and memory footprint wouldn't be worse then > now > > > > on defined set of tests. > > > Right. But once again, without any prototype it's hard to guess the > > > performance changes. > > > > > > Would these requirements fit? > > > a. "The performance DRLVM with UMM enabled should be at least 80% of > > > DRLVM with legacy memory management, as measured by execution on > > > Dacapo, SPECjbb2005 and Eclipse startup". > > > b. "The memory footprint of DRLVM with UMM enabled should be not > > > larger than 120% of DRLVM with legacy memory management, as measured > > > by execution on Dacapo, SPECjbb2005 and Eclipse startup". > > > > > > Though these requirements are more or less loose, they protect from > > > UMM implementation that bloats up the performance or memory footprint > > > many times to be considered successful. > > > > > > Thanks, > > > Aleksey. > > > > > > > > > -- > > Thanks, > > Andrey > > > > > > -- > http://xiao-feng.blogspot.com >
