harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Egor Pasko <egor.pa...@gmail.com>
Subject Re: [drlvm][startup][performance] Implementing futex'es
Date Wed, 13 Feb 2008 09:37:32 GMT
On the 0x3E9 day of Apache Harmony Aleksey Shipilev wrote:
> 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 :)

why guess? just run Harmony under strace on your linux box, you will
see only futexes triggered. Cheers.

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

-- 
Egor Pasko


Mime
View raw message