On 1/10/08, Aleksey Shipilev <[EMAIL PROTECTED]> wrote: > > Hi, Egor! > > On 10 Jan 2008 00:25:48 +0300, Egor Pasko <[EMAIL PROTECTED]> wrote: > > But first we need to make sure if it really happens in this test on > steady state. > I'm going to revisit this issue again tomorrow. > > > > On locking. We should not pay for high profile accurcy sacrificing > > speed of collection (just like we do not lock on edge profiling), but > > I currently have no idea how to modify top-n-value tables in value > > profiling correctly without synchronizing (in fact, one atomic cmpxchg > > would be enough) > (Consider we confirmed the issue with profiler locking) > Yep, CAS is an option. I believe that we can try to implement atomic > increments in profiler under an runtime option, e.g. > -XX:em.useAccurateProfile=false, and then decide which mode should be > default, basically on performance data for some known benchmarks. > > Although, I don't know whether it is safe to: > a. just extend lockProfile() and unlockProfile() to omit mutex calls > b. eliminate locks locally in ValueMethodProfile::addNewValue, AFAIU > for hot method there could be not method-wide locking, but CAS of > num_times_profiled.
Alexey, Omitting the locks at all would be unsafe for TNV table modifications. For your experiments I would try to make increment of num_times_profiled atomic and move profile locks to the else-branch in the addNewValue method (inserting a value to the TNV table). Thanks, Pavel Let's revisit this again next time. > > Thanks, > Aleksey. >
