Openjdk shark and cacao VMs not working

Openjdk shark and cacao VMs not working

[Koen Kooi]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi,

I built openjdk completely from scratch and installed it:

opkg install openjdk-6-common openjdk-6-demo openjdk-6-java
openjdk-6-jdk openjdk-6-jre

opkg install openjdk-6-vm-shark openjdk-6-vm-cacao

That needs to be done in 2 opkg commands since -cacao and -shark edit a
jvm.cfg in their postinst which isn't in their Depends: line. Trivial to
fix, need to sit down and see in which package it resides.

So:

root@beagleboard-C4:~# java -zero Linpack # [1]
Mflops/s: 9.537  Time: 0.07 secs  Norm Res: 1.43  Precision:
2.220446049250313E-16

So far, so good. Better than the 3 Mflops jamvm+classpath gets, but not
as nice as the 16Mflops cacao+classpath can do.

So lets try some other VMs:

root@beagleboard-C4:~# java -shark Linpack
ARMCodeEmitter::emitPseudoInstruction
UNREACHABLE executed at
/OE/angstrom-dev/work/armv7a-angstrom-linux-gnueabi/llvm2.7-2.7-r6/llvm-2.7/lib/Target/ARM/ARMCodeEmitter.cpp:554!
Stack dump:
0.      Running pass 'ARM Machine Code Emitter' on function
'@"Linpack::daxpy"'
Aborted

OK, Xerxes blogged about debugging such issues, but the summer intern is
too busy with other stuff currently.

root@beagleboard-C4:~# java -cacao Linpack
java: avl.c:348: avl_find: Assertion `tree' failed.
Aborted

No idea on that.

Do the java mages have some idea on how to get shark and cacao working well?

regards,

Koen

[1] http://www.netlib.org/benchmark/linpackjava/LinpackJava.zip compiled
with javac on osx
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Darwin)

iD8DBQFMRBzPMkyGM64RGpERAiEJAJ4yeJVBcvuwHzVbS++Zt5iI9Rp11QCgm3aB
Xqj79L9E1QpIz19c0QSxh6o=
=OBoo
-----END PGP SIGNATURE-----

Re: Openjdk shark and cacao VMs not working - shark fixed

[Xerxes Rånby]

Hi Koen!

I have updated the llvm2.7 package to fix the shark
UNREACHABLE executed at ARMCodeEmitter.cpp:554! error
http://cgit.openembedded.org/cgit.cgi/openembedded/commit/?id=d1dcd08e4ec0b65aaaef149bace47da16acf7626

By using those fixes i was able to pass your Linpack testcase:

xerxes@overo:/usr/src/openembedded/shark-test/testcases$
../21jul-2010/j2sdk-image/bin/java -shark Linpack
Mflops/s: 1.063  Time: 0.65 secs  Norm Res: 1.43  Precision:
2.220446049250313E-16

It worked but it looks a bit slow.. I checked why.
it seems Shark are still JITing when the test exits.

I tested to modify the Linpack testcase to run it several times in a row.
by changing the Linpack main to:

  public static void main(String[] args)
  {
    for(int i=0;i<100;i++){
      Linpack l = new Linpack();
      l.run_benchmark();
    }
  }

Now it looks much better:

xerxes@overo:/usr/src/openembedded/shark-test/testcases$
../21jul-2010/j2sdk-image/bin/java -shark Linpack
Mflops/s: 1.068  Time: 0.64 secs  Norm Res: 1.43  Precision:
2.220446049250313E-16
Mflops/s: 14.306  Time: 0.05 secs  Norm Res: 1.43  Precision:
2.220446049250313E-16
Mflops/s: 14.014  Time: 0.05 secs  Norm Res: 1.43  Precision:
2.220446049250313E-16
Mflops/s: 14.306  Time: 0.05 secs  Norm Res: 1.43  Precision:
2.220446049250313E-16
Mflops/s: 14.306  Time: 0.05 secs  Norm Res: 1.43  Precision:
2.220446049250313E-16
LLVM ERROR: ARMv6t2 JIT is not yet supported.

But as you can see I have hited a new LLVM ERROR, and this time because
we are trying to use the thumb2 jit on armv7 hardware.

I have updated the llvm2.7 package once again by backporting more fixes
from the llvm2.8svn branch
http://cgit.openembedded.org/cgit.cgi/openembedded/commit/?id=de16a3d10308c81c7e40886bbe0846604eebdf77

And now when using llvm2.7-2.7-r8 I am able to run the Linpack testcase
for any amount of iterations:

xerxes@overo:/usr/src/openembedded/shark-test/testcases$
../21jul-2010/j2sdk-image/bin/java -shark Linpack
Mflops/s: 1.066  Time: 0.64 secs  Norm Res: 1.43  Precision:
2.220446049250313E-16
Mflops/s: 14.306  Time: 0.05 secs  Norm Res: 1.43  Precision:
2.220446049250313E-16
Mflops/s: 14.014  Time: 0.05 secs  Norm Res: 1.43  Precision:
2.220446049250313E-16
Mflops/s: 14.306  Time: 0.05 secs  Norm Res: 1.43  Precision:
2.220446049250313E-16
Mflops/s: 14.306  Time: 0.05 secs  Norm Res: 1.43  Precision:
2.220446049250313E-16
... about 30 iterations later
Mflops/s: 17.167  Time: 0.04 secs  Norm Res: 1.43  Precision:
2.220446049250313E-16
Mflops/s: 17.607  Time: 0.04 secs  Norm Res: 1.43  Precision:
2.220446049250313E-16
Mflops/s: 17.607  Time: 0.04 secs  Norm Res: 1.43  Precision:
2.220446049250313E-16
...

I am quite happy with those results.
Once we get LLVM and Shark stable then we can drop the Assertions in
LLVM and that will make Shark JIT faster and hopefully get it warm fast
enough to generate good scores for the first iteration of the Linpack
benchmark.

Please report if you find any new Shark issues.

Cheers, and have a great day!
Xerxes

On 2010-07-19 11:37, Koen Kooi wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Hi,
>
> I built openjdk completely from scratch and installed it:
>
> opkg install openjdk-6-common openjdk-6-demo openjdk-6-java
> openjdk-6-jdk openjdk-6-jre
>
> opkg install openjdk-6-vm-shark openjdk-6-vm-cacao
>
> That needs to be done in 2 opkg commands since -cacao and -shark edit a
> jvm.cfg in their postinst which isn't in their Depends: line. Trivial to
> fix, need to sit down and see in which package it resides.
>
> So:
>
> root@beagleboard-C4:~# java -zero Linpack # [1]
> Mflops/s: 9.537  Time: 0.07 secs  Norm Res: 1.43  Precision:
> 2.220446049250313E-16
>
> So far, so good. Better than the 3 Mflops jamvm+classpath gets, but not
> as nice as the 16Mflops cacao+classpath can do.
>
> So lets try some other VMs:
>
> root@beagleboard-C4:~# java -shark Linpack
> ARMCodeEmitter::emitPseudoInstruction
> UNREACHABLE executed at
> /OE/angstrom-dev/work/armv7a-angstrom-linux-gnueabi/llvm2.7-2.7-r6/llvm-2.7/lib/Target/ARM/ARMCodeEmitter.cpp:554!
> Stack dump:
> 0.      Running pass 'ARM Machine Code Emitter' on function
> '@"Linpack::daxpy"'
> Aborted
>
> OK, Xerxes blogged about debugging such issues, but the summer intern is
> too busy with other stuff currently.
>   




> root@beagleboard-C4:~# java -cacao Linpack
> java: avl.c:348: avl_find: Assertion `tree' failed.
> Aborted
>
> No idea on that.
>
> Do the java mages have some idea on how to get shark and cacao working well?
>
> regards,
>
> Koen
>
> [1] http://www.netlib.org/benchmark/linpackjava/LinpackJava.zip compiled
> with javac on osx
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.5 (Darwin)
>
> iD8DBQFMRBzPMkyGM64RGpERAiEJAJ4yeJVBcvuwHzVbS++Zt5iI9Rp11QCgm3aB
> Xqj79L9E1QpIz19c0QSxh6o=
> =OBoo
> -----END PGP SIGNATURE-----
>
>
> _______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
>   

Re: Openjdk shark and cacao VMs not working - shark fixed

[Martin Jansa]

FYI:

Tested on om-gta02 (armv4t) and only -zero seems to work (built from
yesterday oe.dev, waiting for todays fixes to built).

SHR root@gojama ~ $ javac Linpack.java
Warning: no leading - on line 43 of `/usr/lib/jvm/java-6-openjdk/jre/lib/arm/jvm.cfg'
Warning: missing VM type on line 43 of `/usr/lib/jvm/java-6-openjdk/jre/lib/arm/jvm.cfg'
Warning: no leading - on line 43 of `/usr/lib/jvm/java-6-openjdk/jre/lib/arm/jvm.cfg'
Warning: missing VM type on line 43 of `/usr/lib/jvm/java-6-openjdk/jre/lib/arm/jvm.cfg'
dl failure on line 696Error: failed /usr/lib/jvm/java-6-openjdk/jre/lib/arm/shark/libjvm.so, because /usr/lib/libLLVMCodeGen.so: symbol powf, version GLIBCXX_3.4 not defined in file libstdc++.so.6 with link time reference
SHR root@gojama ~ $ javac -zero Linpack.java
Warning: no leading - on line 43 of `/usr/lib/jvm/java-6-openjdk/jre/lib/arm/jvm.cfg'
Warning: missing VM type on line 43 of `/usr/lib/jvm/java-6-openjdk/jre/lib/arm/jvm.cfg'
Warning: no leading - on line 43 of `/usr/lib/jvm/java-6-openjdk/jre/lib/arm/jvm.cfg'
Warning: missing VM type on line 43 of `/usr/lib/jvm/java-6-openjdk/jre/lib/arm/jvm.cfg'

SHR root@gojama ~ $ java -zero Linpack
Warning: no leading - on line 43 of `/usr/lib/jvm/java-6-openjdk/jre/lib/arm/jvm.cfg'
Warning: missing VM type on line 43 of `/usr/lib/jvm/java-6-openjdk/jre/lib/arm/jvm.cfg'
Warning: no leading - on line 43 of `/usr/lib/jvm/java-6-openjdk/jre/lib/arm/jvm.cfg'
Warning: missing VM type on line 43 of `/usr/lib/jvm/java-6-openjdk/jre/lib/arm/jvm.cfg'
Mflops/s: 1.687  Time: 0.41 secs  Norm Res: 1.43  Precision: 2.220446049250313E-16
SHR root@gojama ~ $ java -shark Linpack
Warning: no leading - on line 43 of `/usr/lib/jvm/java-6-openjdk/jre/lib/arm/jvm.cfg'
Warning: missing VM type on line 43 of `/usr/lib/jvm/java-6-openjdk/jre/lib/arm/jvm.cfg'
Warning: no leading - on line 43 of `/usr/lib/jvm/java-6-openjdk/jre/lib/arm/jvm.cfg'
Warning: missing VM type on line 43 of `/usr/lib/jvm/java-6-openjdk/jre/lib/arm/jvm.cfg'
dl failure on line 696Error: failed /usr/lib/jvm/java-6-openjdk/jre/lib/arm/shark/libjvm.so, because /usr/lib/libLLVMCodeGen.so: symbol powf, version GLIBCXX_3.4 not defined in file libstdc++.so.6 with link time reference
SHR root@gojama ~ $ java -cacao Linpack
Warning: no leading - on line 43 of `/usr/lib/jvm/java-6-openjdk/jre/lib/arm/jvm.cfg'
Warning: missing VM type on line 43 of `/usr/lib/jvm/java-6-openjdk/jre/lib/arm/jvm.cfg'
Warning: no leading - on line 43 of `/usr/lib/jvm/java-6-openjdk/jre/lib/arm/jvm.cfg'
Warning: missing VM type on line 43 of `/usr/lib/jvm/java-6-openjdk/jre/lib/arm/jvm.cfg'
LOG: [0x40190000] md_signal_handler_sigill: Unknown illegal instruction 0xed1c5a06 at 0x441c1790
LOG: [0x40190000] Aborting...
Aborted

-- 
Martin 'JaMa' Jansa     jabber: Martin.Jansa@gmail.com

Re: Openjdk shark and cacao VMs not working - shark fixed

[Martin Jansa]

On Wed, Jul 21, 2010 at 4:20 PM, Martin Jansa <martin.jansa@gmail.com> wrote:
> FYI:
>
> Tested on om-gta02 (armv4t) and only -zero seems to work (built from
> yesterday oe.dev, waiting for todays fixes to built).
>
> SHR root@gojama ~ $ javac -zero Linpack.java
> Warning: no leading - on line 43 of `/usr/lib/jvm/java-6-openjdk/jre/lib/arm/jvm.cfg'
> Warning: missing VM type on line 43 of `/usr/lib/jvm/java-6-openjdk/jre/lib/arm/jvm.cfg'
> Warning: no leading - on line 43 of `/usr/lib/jvm/java-6-openjdk/jre/lib/arm/jvm.cfg'
> Warning: missing VM type on line 43 of `/usr/lib/jvm/java-6-openjdk/jre/lib/arm/jvm.cfg'

With current version jvm.cfg warnings are gone, but cacao and shark still fails
SHR root@gojama ~ $ java -zero Linpack
Mflops/s: 1.691  Time: 0.41 secs  Norm Res: 1.43  Precision:
2.220446049250313E-16
SHR root@gojama ~ $ java -cacao Linpack
LOG: [0x40190000] md_signal_handler_sigill: Unknown illegal
instruction 0xed1c5a06 at 0x441c2790
LOG: [0x40190000] Aborting...
Aborted
SHR root@gojama ~ $ java -shark Linpack
dl failure on line 696Error: failed
/usr/lib/jvm/java-6-openjdk/jre/lib/arm/shark/libjvm.so, because
/usr/lib/libLLVMCodeGen.so: symbol powf, version GLIBCXX_3.4 not
defined in file libstdc++.so.6 with link time reference

Let me know if you want more info.

Re: Openjdk shark and cacao VMs not working - armv4 LLVM symbol powf, version GLIBCXX_3.4 not, defined

[Xerxes Rånby]

On 2010-07-22 17:15, Martin Jansa wrote:
> On Wed, Jul 21, 2010 at 4:20 PM, Martin Jansa <martin.jansa@gmail.com> wrote:
>   
>> FYI:
>>
>> Tested on om-gta02 (armv4t) and only -zero seems to work (built from
>> yesterday oe.dev, waiting for todays fixes to built).
>>
>> SHR root@gojama ~ $ javac -zero Linpack.java
>> Warning: no leading - on line 43 of `/usr/lib/jvm/java-6-openjdk/jre/lib/arm/jvm.cfg'
>> Warning: missing VM type on line 43 of `/usr/lib/jvm/java-6-openjdk/jre/lib/arm/jvm.cfg'
>> Warning: no leading - on line 43 of `/usr/lib/jvm/java-6-openjdk/jre/lib/arm/jvm.cfg'
>> Warning: missing VM type on line 43 of `/usr/lib/jvm/java-6-openjdk/jre/lib/arm/jvm.cfg'
>>     
> With current version jvm.cfg warnings are gone, but cacao and shark still fails
> SHR root@gojama ~ $ java -zero Linpack
> Mflops/s: 1.691  Time: 0.41 secs  Norm Res: 1.43  Precision:
> 2.220446049250313E-16
>   
We are quite happy with the current default zero vm in OE since we do
not have any open bugreports for it, it seems stable and nice. :)

> SHR root@gojama ~ $ java -cacao Linpack
> LOG: [0x40190000] md_signal_handler_sigill: Unknown illegal
> instruction 0xed1c5a06 at 0x441c2790
> LOG: [0x40190000] Aborting...
> Aborted
>   
This regression on armv4 and armv5 are most likely caused by the
"armv7" cacao compatible patches bundled with icedtea6-1.8.

I will check if i can see anything obvious and try to debug it.

> SHR root@gojama ~ $ java -shark Linpack
> dl failure on line 696Error: failed
> /usr/lib/jvm/java-6-openjdk/jre/lib/arm/shark/libjvm.so, because
> /usr/lib/libLLVMCodeGen.so: symbol powf, version GLIBCXX_3.4 not
> defined in file libstdc++.so.6 with link time reference
>   
It looks like a different (older?) libstdc++ are used on your phone
compared to whats got used during the build when linking LLVM.
It would be good to check if a LLVM "HelloWorld" can get executed on the
phone.

Please try this LLVM testcase on your phone and report if it work or not:
======== start of file hello.ll
@hello = internal global [12 x i8] c"Hello World\00"

declare i32 @puts(i8*)

define i32 @main() {
    %r = call i32 @puts( i8* getelementptr ([12 x i8]* @hello, i64 0,
i64 0) )
    ret i32 0
}
======== end of file hello.ll
and then execute the following two commands:
llvm-as hello.ll
lli hello.bc

its possible that you have to type
/usr/bin/llvm2.7/llvm-as hello.ll
/usr/bin/llvm2.7/lli hello.bc

If all goes well then you should see.. yes you guessed it:
HelloWorld

If it fail then try updating the libstdc++ to the same version used when
linking llvm.
check if libm are installed.

> Let me know if you want more info.
>   

Re: Openjdk shark and cacao VMs not working - armv4 LLVM symbol powf, version GLIBCXX_3.4 not, defined

[Stefan Ring]

Xerxes Rånby <xerxes <at> zafena.se> writes:

> > SHR root <at> gojama ~ $ java -cacao Linpack
> > LOG: [0x40190000] md_signal_handler_sigill: Unknown illegal
> > instruction 0xed1c5a06 at 0x441c2790
> > LOG: [0x40190000] Aborting...
> > Aborted
> >   
> This regression on armv4 and armv5 are most likely caused by the
> "armv7" cacao compatible patches bundled with icedtea6-1.8.

Regarding the illegal instruction, I don't think that it comes from
the icedtea patch. It sounds like the problem I had in
http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=513.  It went
away when I built CACAO with -mfloat-abi=soft, not with
-mfloat-abi=softfp.

I verified that the current CACAO version works on both armv5 and
armv7. Unfortunately, I don't remember the exact build settings
anymore.