harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mikhail Fursov" <mike.fur...@gmail.com>
Subject Re: [drlvm][jit] A framework to inline API (classlib) methods as magics in JIT
Date Tue, 19 Dec 2006 07:03:11 GMT
On 12/19/06, Xiao-Feng Li <xiaofeng.li@gmail.com> wrote:
> Mikhail, interesting idea.
> Two questions:
> 1. How does JIT knows which API to inline? Does it require the lib
> developers to annotate their code?

JIT knows the names of Java API: for example:
And x86 platform has suitable opcode here: BSR. The knowledge of semantic of
this API method helps JIT to generate more optimized code.  On another
platform, IA64, we have 'bit count' CPU instruction, so we can optimize
another API method.
I checked RI (SUN & BEA) behaviour before making this patch - we were 10
times slower in microtests. Now we are ~20-30% faster. This makes me think
that RI also process such methods like 'magics'.

2. Is it possible to summarize some common ops that are shared by many
> APIs so that only the common ops are inlined.

My proposal was to summarize standardized J2SE API methods that can
optimized with special CPU insts on x86 or IA64 platforms.
I think it must boost our math package performance in some cases.

I am wondering if it's possible to avoid the API case-by-case specific
> inlining, which looks to me not very elegant. :-(  Although the APIs
> are standardized, I feel it's still a little weird to tightly couple
> too many detailed information in JVM. I don't if I am overconcerned.

The only design problem here I see is that API call replacement with native
insts sequence is done in CG while optimizer's inliner must not inline these
calls by itself. Actually I see no elegant solution how to overcome this

Mikhail Fursov

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message