harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alexey Varlamov" <alexey.v.varla...@gmail.com>
Subject Re: [drlvm][performance] VM properties implementation is inefficient
Date Wed, 16 May 2007 06:10:09 GMT
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
>

Mime
View raw message