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 aleksey.shipilev@gmail.com
 designates 72.14.252.153 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=df5P2relUR2JWdD3lQ8L/R7EkBA6fssLhYD8Wdsm54ktp51uKzD1AheFZKWPdc3lwMybTWZ5ScuFCFNC8jzCVBQQhWsELNgVh3D6vyvxavraXTNZv8zWhWItYNtIJjw8GZQF31mHb99bHGhmJFEl8IpYAuo/GywKM5VWeqJZQ0U=
Message-ID: <4bebff790802122258jb5e08b1uf3c668aeadb90849@mail.gmail.com>
Date: Wed, 13 Feb 2008 09:58:35 +0300
From: "Aleksey Shipilev" <aleksey.shipilev@gmail.com>
To: dev@harmony.apache.org
Subject: Re: [drlvm][startup][performance] Implementing futex'es
In-Reply-To: <c30d70960802121638n4dbde520k7c4665c5d3ede2c0@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>
	 <c30d70960802121638n4dbde520k7c4665c5d3ede2c0@mail.gmail.com>

Alexei,

I've also heard that currently pthread mutexes are built on base of
futexes for sake of performance. I don't know what's going on in
EnterCriticalSection on Windows though. That's interesting... I'll
measure the performance with some microbenchmark :)

Thanks,
Aleksey.

On Feb 13, 2008 3:38 AM, Alexei Fedotov <alexei.fedotov@gmail.com> wrote:
> 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
>