Mailing-List: contact dev-help@harmony.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@harmony.apache.org
Received-SPF: pass (athena.apache.org: domain of alexei.fedotov@gmail.com
 designates 66.249.92.169 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references;
        b=vI5KkOdrKSCXCGHicAZzCx9UbtG0dztEMh1PvlcHuSo9wvyDzJV6EeK1ZDpjrVEsPwwHGIcny01FjhIGK+X/hKT88pkzDulTEf3U3t39ChLpGgeAgy4LLZTg+UxVRvrwVAcwCZIoQPKrfpWr3okKfczlVIfS0InXmoNtmPq9/4Q=
Message-ID: <c30d70960802121638n4dbde520k7c4665c5d3ede2c0@mail.gmail.com>
Date: Wed, 13 Feb 2008 03:38:23 +0300
From: "Alexei Fedotov" <alexei.fedotov@gmail.com>
To: dev@harmony.apache.org
Subject: Re: [drlvm][startup][performance] Implementing futex'es
In-Reply-To: <4bebff790802121512x58533dabg9e426d440e798166@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <4bebff790802121512x58533dabg9e426d440e798166@mail.gmail.com>

Hello Aleksey,
Is not the current mutex implementation no less efficient than futex?
I've heard that mutexes try to spin before switching to kernel, and
Windows critical sections do the same trick.

Thanks!

On Feb 13, 2008 2:12 AM, Aleksey Shipilev <aleksey.shipilev@gmail.com> wrote:
> Hi, Alexei, all,
>
> Just another idea for startup optimizations pops out of our talk with
> Egor Pasko. :)
>
> As you probably know there are many places in VM and JIT that use
> locking for safety reasons. Most of this locking is driven by mutexes,
> that is, the kernel calls. That's a good option in case of contention,
> because such locking will need arbitration (e.g. "who will take the
> mutex next"?) from kernel side. But what if that locking is not
> contended? Even then we will make the kernel call for trying to catch
> the mutex.
>
> Linux has long ago implemented such thing as "fast user-space mutex",
> "futex" [1]. Generally it is simple memory region that could be
> incremented/decremented atomically. In case of contention futex, of
> course, will resort to kernel-side mutex.
>
> That mean we could save precious time using futexes instead of
> mutexes: we definitely will save on kernel call time.
>
> AFAIK, current implementation of porting layer has no support for
> futexes even on Linux side. And so we might try to implement them for
> Windows part and use the Linux-provided futex'es on Linux part. Then
> after the implementation of hyfutex_lock/unlock we might try to
> migrate performance-significant locks to futexes one-by-one. Profilers
> are good directions, maybe anywhere else too.
>
> What do you think?
>
> Thanks,
> Aleksey,
> ESSD, Intel
>
> [1] http://en.wikipedia.org/wiki/Futex
>


-- 
With best regards,
Alexei