Mikhail, I'd also add j.l.System.arraycopy() to the list, see HARMONY-2247 (System::arraycopy by 'rep move' instruction).
2006/12/19, Xiao-Feng Li <[EMAIL PROTECTED]>:
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.
Seems that inline opportunities are highly platform-dependent here, so IMO there is almost no sense in annotating them at general high-level API. Abstracting JVM as a mediator between Java API and hardware, it is not weird to embed low-level platform specific details into it - not very elegant indeed but not queer. BTW, term "inlining" may be a bit misleading in this topic, rather "intrinsic replacement" or "magics substituion". -- Alexey
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 > >
