harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ligang Wang" <wanglg9...@gmail.com>
Subject Re: [GSoC] Appliance for harmony-gc-4 "Unify the native memory management of Harmony DRLVM"
Date Wed, 02 Jul 2008 06:38:44 GMT
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 <xiaofeng.li@gmail.com> wrote:
>
> On Thu, Apr 3, 2008 at 9:41 PM, Andrey Yakushev
> <andrey.yakushev@gmail.com> 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 <aleksey.shipilev@gmail.com> wrote:
> >
> >
> > > On Wed, Apr 2, 2008 at 3:15 PM, Andrey Yakushev
> >  > <andrey.yakushev@gmail.com> 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
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message