harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Aleksey Shipilev" <aleksey.shipi...@gmail.com>
Subject Re: [performance] quick sort is 4x slower on Harmony
Date Wed, 09 Jan 2008 22:17:32 GMT
Hi, Egor!

On 10 Jan 2008 00:25:48 +0300, Egor Pasko <egor.pasko@gmail.com> 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.

Mime
View raw message