[Fwd: Optimizing JVM for running java extensions]

[Maxim Kizub]

Maxim Kizub wrote:
> 
> Hello.
> 
> Kiev introduses some extensions to java language,
> you know.
> 
> The problem is that many of them are impossible
> to implement in optimal way - JVM bytecode does
> no allow any kind of extensions.
> 
> For example, parametriezed types may not be
> represented in JVM. To emulate them, kiev compiler
> (and pizza and others) needs insert op_checkcast
> opcode at each access to parametriezed value.
> Any king of work with parameter types are not
> allowed or must be emulated by very cost
> operations. Pizza simply strips this additional
> information, kiev uses slow reflection.
> For example,
> 
> class C<A> {
>         A[]     arr;
>         A       a;
>         C foo(int i, Object o) {
>                 // Kiev uses reflection to create
>                 // new array
>                 arr = new A[i];
> 
>                 // In general not possible, since
>                 // not all classes have "empty"
>                 // constructor, and reflection allows
>                 // to use only "empty" constructors
>                 a = new A();
> 
>                 // Kiev uses a slow mechanizm with
>                 // using of kiev.lang.TypeInfo fields
>                 if ( o instanceof A ) {
>                         ...
>                 }
>         }
> }
> 
> Implementation of full support of type parametrization
> is a) impossible, b) slow in emulation of those cases,
> when this is possible somehow.
> 
> Next example is first-order functions, method references
> and closures. There are two approaches - pizza uses
> special-generated class with methods, that used as
> proxy to access real code, plus uses Object[] array
> to pass arguments. Kiev uses inner class for each
> method reference/closure, but is faster in invokation
> of method refs and closures, since it can send arguments
> directly, like in method calls.
> 
> So, both these approaches are slow and takes more memory
> than possible. This becomes the real pain in applications
> that try to use these features intensively.
> 
> The same is for prolog subsystem of kiev compiler.
> Lack of tail-recursion calls prevents efficient
> implementation of any language from prolog or lisp/scheme
> family.
> 
> Some other extensions may be implemented much more
> memory efficient or faster. Additionally, emulation
> of features, that not supported by JVM directly
> requires a set of complex conventions in code
> generation, that are not very clean and very
> hard to implement.
> 
> To solve these problems for kiev language and other
> languages, that uses JVM as compilation target,
> we tryed to extend JVM to add native support for
> the most slow or memory hungry (in emulation mode)
> features.
> 
> We've taken kaffe JVM ( http://www.transvirtual.com ),
> and added functionality for native support for
> type parametrization and first-order functions and
> closures. We have plans to add functionality for
> tail-recursion calls also.
> 
> If anyone intrested in this extended JVM - we may
> put on the web version of kaffe for Linux i386 and
> kiev compiler version that able generate bytecode
> for this kaffe JVM.
> 
> Also, we need to know your opinion about these
> extensions and the direction you'd like to see
> in our work.
> 
> First, kaffe is very partable JVM. Unfortunatly,
> it has problems with Win32 compilation. We may
> solve this problem, putting Win32 version
> on our download page, if there are enough users
> that needs it. Second, kaffe lacks of Win32 AWT
> libraries. Third, kaffe compiles unoptimized
> native code, so, if you do not use type parametrization
> and first-order functions/closures very offten -
> your applications will run slower, that with
> Sun's JVM+JIT or MS JVM.
> In our case (Linux i386 Blackdown port of
> Sun's JVM v 1.1.7 + TYA JIY 1.0) were about
> 1.4 times faster, than kaffe JVM.
> If this is the main problem for you - we may
> work with kaffe team in direction of
> bytecode optimization.
> 
> Another approach is to patch Sun's JVM to add
> native support for those fetures.
> The problem is that without JIT it will be
> much slower, than unpatched version. So,
> we need to add support for these JVM extensions
> to JIT also. Under Linux we have sources of
> TYA JIT, and may contact it's author or
> add this support ourselfs. But we don't
> know how to solve this JIT problem for
> other platforms, for example, for Win32.
> Anyway, this is also a possible approach,
> and there is no problems, that can't be solved ;-)
> 
> We need your feedback to know where to go!
> 
> PS Test.java and benchmarks of closure/first-order
> functions are attached.
> 
> In short :
> 1. loop of calls to static ()->void
> 2. loop of creation of static ()->void and call it
> 3. loop of calls to static (int,long,float,double,String)->void
> 4. loop of creation and calls to static
> (int,long,float,double,String)->void
> 5. as 1, but for virtual closure
> 6. as 2, but for virtual closure
> 7. as 3, but for virtual closure
> 8. as 4, but for virtual closure
> 
> Counts are nanoseconds per one loop iteration.
> 
>               1     2      3      4     5      6      7      8
> kiev opt   1320  9510   1920  18610  1350   8950   1800  18270
> pizza      2380 14230  77740  97840  2310  14330  77700  98170
> kiev unopt 1090 12900 164000 215290  1330  14700 158730 210550
> 
>               1     2      3      4     5      6      7      8
> kiev opt   1.00  1.00   1.00   1.00  1.00   1.00   1.00   1.00
> pizza      1.80  1.50  40.49   5.26  1.71   1.60  43.17   5.37
> kiev unopt 0.82  1.36  85.42  11.57  0.96   1.64  88.18  11.52
> 
> Also. pizza was unable to compile test like
> (int,long,float,double,String)->void v1 = ...
> ()->void v2 = v1(0,0L,0.F,0.D,"test");
> v2();
> 
> So, these tests were removed from Test.java
> 
> Regards
>   Maxim Kizub
> 
>   ------------------------------------------------------------------------
> 
>                    Name: Test.java
>    Test.java       Type: Plain Text (text/plain)
>                Encoding: 7bit
> 
>                     Name: benchmarks
>    benchmarks       Type: Plain Text (text/plain)
>                 Encoding: 7bit