harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mikhail Fursov" <mike.fur...@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:02:28 GMT
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
Here the most simple implementation of this feature I can imagine:

the method:
Class getClass();

gets an annotation in sources like:


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

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