30 Oct 2006 11:03:50 +0600, Egor Pasko <[EMAIL PROTECTED]>:

On the 0x212 day of Apache Harmony Tonny Lau wrote:
> Hi,
>
> I want to override some specific java methods with native fast path
> implementations. So I try to override them in
> compile_do_compilation_jit()(vm/vmcore/src/jit/compile.cpp), that is,
> I add several entries in
>
_stub_override_entries_base[](vm/vmcore/src/util/ia32/base/compile_IA32.cpp),
> and lookup this table
> before invoke jit->compile_method_with_params().

This mechanism is not used (AFAIR and AFAICanSeeNow). The alternative
way is to support your "magics" within each JIT. (Mikhail does things
like that in OPT just from JavaByteCodeTranslator.cpp (see
isMagicClass(...))


Thanks! I'll look it.

It works for JET, but failed when OPT recompile these method. Does the OPT
> go different path? If so, how can I override it? Does anyone can help
me?

how does it fail? did you try it with -Xem:opt? (That's what I tend
to always ask about:)

Just a guess: OPT expects some profile from JET, but cannot find any.


I mean, the overriding succeeds when I use JET only, i.e., "java -
Dem.properties=jet ...". If I use the default configuration "java ...", at
the beginning, the overriding is successful because the code is compiled by
JET. But later, when the EM invoke OPT to re-compile the hot code, the
overriding does not work any longer. It fall back to the original java code.

So, where do you think is the best place in OPT for the overriding code? And
is there a common path for both JET and OPT?


--
Egor Pasko, Intel Managed Runtime Division


Reply via email to