harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alexei Fedotov" <alexei.fedo...@gmail.com>
Subject Re: [drlvm][performance] VM properties implementation is inefficient
Date Mon, 28 May 2007 10:02:26 GMT
Hello, Ilya,

This is a very interesting thread. Let me ask few questions to
understand the subject better.

I have tried VTune and it didn't mark property access in the verifer
as a hot spot. Could you please share more details of your experiment?
Reading which property affects a performance? What is expected benefit
from caching this property value in the verifier?

Thank you, Alexei


On 5/17/07, Evgueni Brevnov <evgueni.brevnov@gmail.com> wrote:
> On 5/16/07, Ilya Berezhniuk <ilya.berezhniuk@gmail.com> wrote:
> > 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.
>
> Probably I miss something here but why we should read the property
> each time? We can just have a special flag indicating that property
> has changed and its cashed value must be updated.
>
> Thanks
> Evgueni
> >
> > 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
> >
>


-- 
With best regards,
Alexei,
ESSD, Intel

Mime
View raw message