On 4/5/07, Rana Dasgupta <[EMAIL PROTECTED]> wrote:
On 4/5/07, Gregory Shimansky <[EMAIL PROTECTED]> 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.
-Nathan
