2007/5/12, Ilya Berezhniuk <[EMAIL PROTECTED]>:
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 <[EMAIL PROTECTED]>:
>
> 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
