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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> wrote: > On 5/16/07, Ilya Berezhniuk <[EMAIL PROTECTED]> 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 <[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 > > > -- With best regards, Alexei, ESSD, Intel
-- Pavel Pervov, Intel Enterprise Solutions Software Division
