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.
