harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sergey Kuksenko" <sergey.kukse...@gmail.com>
Subject Re: [drlvm][jit][performance] Suggestion: Let's write some small and hot native(kernel) methods on vmmagics.
Date Thu, 17 May 2007 15:11:24 GMT
Mikhail,
I wrote about it:
 "From the other side it is incorrect having a main implemenation of these
methods on vmmagics. Because it needs to support vmmagics in interpreter
and/or any jit. Jitrino supports vmmagics, but for classlib implementation
we shouldn't rely on such support from JIT side."
That if JIT supports vmmagics then it should replace calls of original
methods to vmmagic-based methods.
The idea with annotations is good. But I have a question, where(in which
class/jar) should be located magic version of method?



On 5/17/07, Mikhail Fursov <mike.fursov@gmail.com> wrote:
>
> Sergey,
> I support your idea. And we should not forget that the code we have in
> kernel classes must work with JITs and interpreters that do not support
> vmmagics.
> Here the most simple implementation of this feature I can imagine:
>
> the method:
> Class getClass();
>
> gets an annotation in sources like:
>
> @VMMagicVersion=thisclass::magicMethodName
>
> and if JIT knows about this annotation and supports vmmagics inlining it
> can
> replace all getClass calls with magicMethod calls.
>
> What do you think about it?
>
>
>
> On 5/17/07, Sergey Kuksenko <sergey.kuksenko@gmail.com> wrote:
> >
> > Hi All,
> >
> > I'd like to suggest a performance improvement for Harmony DRLVM.
> > There is a fact that cost of calling small JNI methods is rather high.
> > From the other side there are a vmmagics methods which allows to
> implement
> > such small methods directly on Java and generates a good and fast code.
> >
> > For example:
> > Currently Object.getClass() works 8 times slower on DRLVM than on SUN
> VM.
> > This is because right now getClass() is JNI method.
> > We've done an experiment and rewrote the method on vmmagics.
> > For a small micro (iteration over getClass() call) we've got the
> following
> > improvement 11 sec -> 2,2 sec.
> > Speeup is 5x times.
> > Also we played with Thread.currentThread() method and got a good
> > performance
> > boost on Dacapo benchmark.
> > For SciMask methods Double.doubleToLongBits() and
> Double.longBitsToDouble
> > ()
> > should be done on vmmagics.
> > And etc....
> >
> > From the other side it is incorrect having a main implemenation of these
> > methods on vmmagics. Because it needs to support vmmagics in interpreter
> > and/or any jit. Jitrino supports vmmagics, but for classlib
> implementation
> > we shouldn't rely on such support from JIT side.
> >
> > Our goal is substituting a several hot native functions to magic-based
> > implementation.
> > As well we will detect such hot methods in old or new benchmarks it
> makes
> > sense to do such substitution (if it is possible).
> > Thus it is better to have a good framework for it.
> > From the other side we already have a part of such framework, If we look
> > into helper inline.
> >
> > Other words helper inline can be divided into two parts:
> >
> > -        Substitute direct call of helper method (asm or LIL based) to
> > separately pointed Java method. These Java methods are usually
> > magic-based,
> > but in general they can be pure Java, if it is enough.
> >
> > -        Inline these replacing methods.
> > So all that we need here is implement yet another substitor, which will
> > substitute some calls of some methods to  calls of vmmagic-based
> variants
> > and after that JIT can used the inliner from helper inline.
> > Having such optimization allows to get a reasonable performance for some
> > selected list of JNI methods.
> >
> > --
> > Best regards,
> > ---
> > Sergey Kuksenko.
> > Intel Enterprise Solutions Software Division.
> >
>
>
>
> --
> Mikhail Fursov
>



-- 
Best regards,
---
Sergey Kuksenko.
Intel Enterprise Solutions Software Division.

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