[drlvm][jit][performance] Suggestion: Let's write some small and hot native(kernel) methods on vmmagics.

[Sergey Kuksenko <se...@gmail.com>]

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.

Re: [drlvm][jit][performance] Suggestion: Let's write some small and hot native(kernel) methods on vmmagics.

[Egor Pasko <eg...@gmail.com>]

On the 0x2DA day of Apache Harmony Mikhail Fursov wrote:
> Alexey,
> any public method can delegate execution to a private one. The private
> methods are not under specs. Using this pattern we will not expose any
> implementation specific annotation to end users

OK then, thank you for clarification

> On 5/18/07, Alexey Varlamov <al...@gmail.com> wrote:
> >
> > 2007/5/18, Mikhail Fursov <mi...@gmail.com>:
> > > On 18 May 2007 00:36:06 -0700, Egor Pasko <eg...@gmail.com> wrote:
> > > >
> > > > On the 0x2D9 day of Apache Harmony Mikhail Fursov wrote:
> > > > > On 5/18/07, Alexey Varlamov <al...@gmail.com> wrote:
> > > > > >
> > > > > > 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.
> > > > >
> > > > >
> > > > > It's good to restrict magics  to be used only  in bootstrap classes.
> > In
> > > > this
> > > > > case I see no security problems. (?)
> > > >
> > > > Does The Standard allow extra unspecified annotations in bootstrap
> > > > classes?
> > >
> > >
> > > I know that it does not say anything about privates. With help of
> > @Inline
> > > pragma it's enough.
> >
> > Egor probably meant annotations on those public methods to be replaced
> > by magics - then this is the same question as I meant above saying "As
> > long as annotations are not a part of specifications".
> > The short answer is: only TCK knows. More detailed answer is:
> > 1) Annotations are listed in javadocs and probably should be checked by
> > the JCK;
> > 2) Extra annotations do not affect compatibility in any way and should
> > be allowable from common POV.
> >
> > >
> > > --
> > > Mikhail Fursov
> > >
> >
> 
> 
> 
> -- 
> Mikhail Fursov

-- 
Egor Pasko

Re: [drlvm][jit][performance] Suggestion: Let's write some small and hot native(kernel) methods on vmmagics.

[Mikhail Fursov <mi...@gmail.com>]

Alexey,
any public method can delegate execution to a private one. The private
methods are not under specs. Using this pattern we will not expose any
implementation specific annotation to end users


On 5/18/07, Alexey Varlamov <al...@gmail.com> wrote:
>
> 2007/5/18, Mikhail Fursov <mi...@gmail.com>:
> > On 18 May 2007 00:36:06 -0700, Egor Pasko <eg...@gmail.com> wrote:
> > >
> > > On the 0x2D9 day of Apache Harmony Mikhail Fursov wrote:
> > > > On 5/18/07, Alexey Varlamov <al...@gmail.com> wrote:
> > > > >
> > > > > 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.
> > > >
> > > >
> > > > It's good to restrict magics  to be used only  in bootstrap classes.
> In
> > > this
> > > > case I see no security problems. (?)
> > >
> > > Does The Standard allow extra unspecified annotations in bootstrap
> > > classes?
> >
> >
> > I know that it does not say anything about privates. With help of
> @Inline
> > pragma it's enough.
>
> Egor probably meant annotations on those public methods to be replaced
> by magics - then this is the same question as I meant above saying "As
> long as annotations are not a part of specifications".
> The short answer is: only TCK knows. More detailed answer is:
> 1) Annotations are listed in javadocs and probably should be checked by
> the JCK;
> 2) Extra annotations do not affect compatibility in any way and should
> be allowable from common POV.
>
> >
> > --
> > Mikhail Fursov
> >
>



-- 
Mikhail Fursov

Re: [drlvm][jit][performance] Suggestion: Let's write some small and hot native(kernel) methods on vmmagics.

[Alexey Varlamov <al...@gmail.com>]

2007/5/18, Mikhail Fursov <mi...@gmail.com>:
> On 18 May 2007 00:36:06 -0700, Egor Pasko <eg...@gmail.com> wrote:
> >
> > On the 0x2D9 day of Apache Harmony Mikhail Fursov wrote:
> > > On 5/18/07, Alexey Varlamov <al...@gmail.com> wrote:
> > > >
> > > > 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.
> > >
> > >
> > > It's good to restrict magics  to be used only  in bootstrap classes. In
> > this
> > > case I see no security problems. (?)
> >
> > Does The Standard allow extra unspecified annotations in bootstrap
> > classes?
>
>
> I know that it does not say anything about privates. With help of @Inline
> pragma it's enough.

Egor probably meant annotations on those public methods to be replaced
by magics - then this is the same question as I meant above saying "As
long as annotations are not a part of specifications".
The short answer is: only TCK knows. More detailed answer is:
1) Annotations are listed in javadocs and probably should be checked by the JCK;
2) Extra annotations do not affect compatibility in any way and should
be allowable from common POV.

>
> --
> Mikhail Fursov
>

Re: [drlvm][jit][performance] Suggestion: Let's write some small and hot native(kernel) methods on vmmagics.

[Mikhail Fursov <mi...@gmail.com>]

On 18 May 2007 00:36:06 -0700, Egor Pasko <eg...@gmail.com> wrote:
>
> On the 0x2D9 day of Apache Harmony Mikhail Fursov wrote:
> > On 5/18/07, Alexey Varlamov <al...@gmail.com> wrote:
> > >
> > > 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.
> >
> >
> > It's good to restrict magics  to be used only  in bootstrap classes. In
> this
> > case I see no security problems. (?)
>
> Does The Standard allow extra unspecified annotations in bootstrap
> classes?


I know that it does not say anything about privates. With help of @Inline
pragma it's enough.

-- 
Mikhail Fursov

Re: [drlvm][jit][performance] Suggestion: Let's write some small and hot native(kernel) methods on vmmagics.

[Egor Pasko <eg...@gmail.com>]

On the 0x2D9 day of Apache Harmony Mikhail Fursov wrote:
> On 5/18/07, Alexey Varlamov <al...@gmail.com> wrote:
> >
> > 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.
> 
> 
> It's good to restrict magics  to be used only  in bootstrap classes. In this
> case I see no security problems. (?)

Does The Standard allow extra unspecified annotations in bootstrap classes?

> 2007/5/17, Sergey Kuksenko <se...@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.
> >
> > We can write magic method in the same class with original. Are there any
> potential problems with it?
> 
> -- 
> Mikhail Fursov

-- 
Egor Pasko

Re: [drlvm][jit][performance] Suggestion: Let's write some small and hot native(kernel) methods on vmmagics.

[Mikhail Fursov <mi...@gmail.com>]

On 5/18/07, Alexey Varlamov <al...@gmail.com> wrote:
>
> 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.


It's good to restrict magics  to be used only  in bootstrap classes. In this
case I see no security problems. (?)

2007/5/17, Sergey Kuksenko <se...@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.
>
> We can write magic method in the same class with original. Are there any
potential problems with it?

-- 
Mikhail Fursov

Re: [drlvm][jit][performance] Suggestion: Let's write some small and hot native(kernel) methods on vmmagics.

[Alexey Varlamov <al...@gmail.com>]

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 <se...@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 <mi...@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 <se...@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.
>

Re: [drlvm][jit][performance] Suggestion: Let's write some small and hot native(kernel) methods on vmmagics.

[Sergey Kuksenko <se...@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?



On 5/17/07, Mikhail Fursov <mi...@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 <se...@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.

Re: [drlvm][jit][performance] Suggestion: Let's write some small and hot native(kernel) methods on vmmagics.

[Mikhail Fursov <mi...@gmail.com>]

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 <se...@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