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. Let's revisit this again next time. Thanks, Aleksey.
