harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alexey Varlamov" <alexey.v.varla...@gmail.com>
Subject Re: [drlvm][jit][performance] Suggestion: Let's write some small and hot native(kernel) methods on vmmagics.
Date Fri, 18 May 2007 05:01:09 GMT
As long as annotations are not a part of specifications, and magic
impls are general enough to not depend on runtime configuration
(particular VM components etc), this approach looks neat.
Another issue with using arbitrary magics is potential risk of
security breaches; we need to think how to control & restrict origin
of magic codes - like allowing only predefined bootstrap packages a la
"org.apache.harmony.security.fortress" or introducing & checking
dedicated security permissions.

2007/5/17, Sergey Kuksenko <sergey.kuksenko@gmail.com>:
> 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?

This one is easy - either package magics along with the supported
classes, this only adds 1 external dependency to vmmagic.jar; or
package them separately as <module>-magics.jar and handle via
bootclasspath.properties as any other jar.

>
> 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
View raw message