harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Pavel Pervov" <pmcfi...@gmail.com>
Subject Re: [drlvm][performance] VM properties implementation is inefficient
Date Mon, 28 May 2007 10:09:06 GMT
This access in verifier stub was removed recently (and property value
cached), when class file parser was improved. So, this is not the hot spot
anymore.

WBR,
    Pavel.


On 5/28/07, Alexei Fedotov <alexei.fedotov@gmail.com> wrote:
>
> 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
>



-- 
Pavel Pervov,
Intel Enterprise Solutions Software Division

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