harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Nathan Beyer" <ndbe...@apache.org>
Subject [native] mfence alternative WAS: [general] What platforms do we support?
Date Fri, 06 Apr 2007 18:56:47 GMT
I found this interesting article about the Linux kernel's approach to
using SSE2 fence operations [1] when available. Perhaps we can use a
similar technique to implement the memory barriers in the static
native code.

Anyone have thoughts or comments about this? Can this technique be
ported to windows platforms?


[1] http://lwn.net/Articles/164121/

---------- Forwarded message ----------
From: Nathan Beyer <ndbeyer@apache.org>
Date: Apr 5, 2007 7:09 PM
Subject: Re: [general] What platforms do we support?
To: dev@harmony.apache.org

On 4/5/07, Rana Dasgupta <rdasgupt@gmail.com> wrote:
> On 4/5/07, Gregory Shimansky <gshimansky@gmail.com> wrote:
> > On Thursday 05 April 2007 02:25 Nathan Beyer wrote:
> > > Yes, I believe what we want to say is code to the lowest common
> > > instruction set for static code in the VM, at least for each distinct
> > > instruction set (x86 32-bit, IPF, etc). For the x86 32-bit, the
> > > available instructions must be available in at least a P3.
> >
> > I don't quite understand why code patching doesn't help here? Classlib hythr
> > code does code patching to remove lock prefixes for some instructions (see
> > files in modules/portlib/src/main/native/thread/windows/windows.x86 and
> > modules/portlib/src/main/native/common/windows/lock386.c) on uniprocessors,
> > same could be done to patch away mfence and sfence.
> >
> >
> Technically, there is no reason why it cannot be dynamically patched
> as you describe. But if tomorrow there is a new helper that uses a
> fast platform library for memcpy that uses some SSE2 ( as eg., AMD
> fast memcpy does ) you will need to patch that too. If we want to
> support PIII, probably the simplest way is to restrict ourselves to
> the PIII instruction set and only let the jit detect platform and
> generate more advanced instruction sequences. There is no perf etc.
> loss in this because in any case, we want the applications to spend
> almost all their time in jitted code.

This would be the approach I think is most appropriate. We want to
minimize the static native code anyway. Additionally, just coding to
the lowest common instruction set would keep the code much cleaner and
easier to maintain.


View raw message