Mikhail Fursov wrote:
JET replies on SSE2 instructions and this patch does not fix it. The patch
fixes only OPT.
"client" mode contains JET as a first JIT, but I added code to JET to check
if SSE2 is available and refuse compilation if not.
The second JIT in 'client' mode is OPT and after JET is refused to
compile a
method, OPT compiles it.
I have another idea to check in JET if method contains double ops and
compile it if it does not. It will improve startup time and JVMTI support
significantly before JET is able to support 'doubles' on i586, because of
only small number of methods use doubles.
But I do not want putting all the changes into the same patch and propose
moving by small steps.
My proposal is committing this patch (after p3 is renamed to 'i586') and
open new JIRAs for every problem we have like
1) support doubles in JET for non-SSE2 platforms
2) various bugs on i586 platforms
3) making JET compile methods without doubles on i586 until item1) is
ready.
What do you think on this?
I can guess now why JVMTI tests are failing. JVMTI relies heavily on JET
because only JET implements functions like get_bc_location_for_native
and get_native_location_for_bc. When JVMTI mode is enabled on the
command line (e.g. something like -agentlib or -agentpath is specified),
EM chooses ti.emconf instead of the default client.emconf file which
defines only one JIT chain - JET_TI. If JET refuses to compile the
methods, and there is no 2nd chain, the program won't be executed.
--
Gregory
