harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ilya Berezhniuk" <ilya.berezhn...@gmail.com>
Subject Re: [drlvm][performance] VM properties implementation is inefficient
Date Wed, 16 May 2007 12:29:27 GMT
Alexey!

Thanks for idea, I agree that adding getters to Properties class can be a
best solution.
I'll try to implement this approach and check performence.

Regarding caching flag in verifier: unfortunately, verifier must read this
flag every time and cannot cache it, because corresponding property can be
changed by uncontrolled code.

2007/5/16, Alexey Varlamov <alexey.v.varlamov@gmail.com>:
>
> 2007/5/12, Ilya Berezhniuk <ilya.berezhniuk@gmail.com>:
> > Thank you, Rustem!
> >
> > I was wondered with these results too. It's my fault; I actually used
> > default heap size for SPECjbb.
> >
> > It means that real gain is much lower.
> > But if these modifications affect native part only, and its effect is
> > significant, I think it can be reasonable anyway.
> >
> >
> > Evgueni,
> >
> >  One of hotspots I've found is using properties is verifier. It checks
> > verifier flags every time when invoked.
>
> Shouldn't we fix the verifier then - to cache flags or such?
> My point is that properties have established and safe interface now,
> and see no persuasive reason to change it. Of course it is possible to
> optimize impl - say, by using specialized allocator instead of malloc,
> or enrich Properties class with get_boolean()/get_int() members to
> avoid intermediate copying in some cases (currently this is part of VM
> C interface impl with extra overhead).
>
> > AFAIK, the count of properties is incomparably fewer than count of
> strings
> > parsed from class constant pools.
> > And loader_env->string_pool is already used to store constant strings,
> the
> > names of loaded libraries in natives support for example.
>
> I second Evgueni here, using String_Pool for collecting everything is
> undesirable - this is quite stressed storage, we rather should try to
> reduce overhead on it.
>
> --
> Alexey
>
> >
> >
> > 2007/5/11, Rustem Rafikov <r.v.rafikov@gmail.com>:
> > >
> > > Hi All,
> > >
> > > Indeed, ~95% of time we spend in jitted code when running jbb2005.
> > > Other %% are spreaded among native code, no one module takes > 2-3%.
> > >
> > > I've just cheked the patch on jbb2005 @ win32 (prescott and woodcrest,
> > > both
> > > gvc4.1 and gcv5) and linux64 (woodcrest, gcv4.1).
> > > 1.5G heap was used. No boost has been measured. All difference is in
> > > uncertainty range (< 1%).
> > >
> > > An assumption may be that 2.41% boost was measured with default heap
> size
> > > and impact of native code was higher in this case.
> > >
> > > --
> > > Thanks,
> > > Rustem
> > >
> >
> >
> >
> > --
> >
> > Ilya
> >
>



-- 

Ilya

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