Mikhail, interesting idea. Two questions: 1. How does JIT knows which API to inline? Does it require the lib developers to annotate their code? 2. Is it possible to summarize some common ops that are shared by many APIs so that only the common ops are inlined.
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. Btw, VM helper inlining boosts GCv5 performance substantially, especially due to the write barrer inlining. :-) Thanks for your big helps. Thanks, xiaofeng On 12/18/06, Mikhail Fursov <[EMAIL PROTECTED]> wrote:
All, Some of API methods like java/lang/Math or Integer/Long bits related ones on some platforms could be replaced with effective native instructions. I call these methods API magics, because they are close to vmmagics we use to inline VM helper: when a set of known Java methods is replaced by JIT with associated native code. Some of API magics like Math.min/max/abs are processed in translator to HIR -> they have analogous ops in HIR. In http://issues.apache.org/jira/browse/HARMONY-2778 I have added codegenerator's part of the framework for the methods that have LIR analogues. Now code contains inlining for some bits manipulation methods for IA32/EM64T platform for Integer and Long classes. I chose these methods because of the SpecJBB2000 impact (rather small but measurable). I'm asking to review the code of fast-path methods versions and to collect the whole list of API magics JIT can inline. The implementation of new "api magics" could be an interesting task for new JIT developers. AFAIK the current list is *java/lang/Math:[any platform] max min abs *java/lang/Integer:[x86] numberOfTrailingZeros numberOfLeadingZeros *java/lang/Long:[x86] numberOfTrailingZeros numberOfLeadingZeros So it's very, very short today. -- Mikhail Fursov
