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 <[EMAIL PROTECTED]>:
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 >
-- Ilya
