harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Pavel Ozhdikhin" <pavel.ozhdik...@gmail.com>
Subject Re: [performance] quick sort is 4x slower on Harmony
Date Thu, 10 Jan 2008 07:23:16 GMT
On 1/10/08, Aleksey Shipilev <aleksey.shipilev@gmail.com> wrote:
>
> 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.



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.
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message