harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Xiao-Feng Li" <xiaofeng...@gmail.com>
Subject Re: [drlvm][jit] A framework to inline API (classlib) methods as magics in JIT
Date Tue, 19 Dec 2006 03:43:43 GMT
On 12/19/06, Alexey Varlamov <alexey.v.varlamov@gmail.com> wrote:
> 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 <xiaofeng.li@gmail.com>:
> > 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".

"intrinsic substitution" sounds to hit the point. :-)

I didn't mean to be against the idea of instrinc substitution, just
feel (intruitively, not necessarily reasonably) there are some
approach to make the work systematic, instead of  identifying the
method/class one by one.  For example, to categorize the intrinsics
domains into some common subroutines.

Well just two cents, don't know if there is better approach than what
Mikhail proposed.

Thanks,
xiaofeng

> --
> 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 <mike.fursov@gmail.com> 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
> > >
> > >
> >
>

Mime
View raw message