Advogato blog for twisti

Latest JSR 292 performance work

Wed, 24 Aug 2011 15:04:42 GMT

It's been a long time since my last post (over a year) and in the meantime we have released JDK 7 with JSR 292 support. Right now I'm working on JSR 292 performance and which should be included in the next JDK 7 update (7u) release.

I just sent out an email to the mlvm-dev mailing list with some JRuby performance numbers for:

7079673: JSR 292: C1 should inline bytecoded method handle adapters

I paste them here again for convenience.

intelsdv07:~/mlvm/jruby$ jruby -J-showversion --client bench/bench_fib_complex.rb 5 35
java version "1.7.0"
Java(TM) SE Runtime Environment (build 1.7.0-b147)
Java HotSpot(TM) Client VM (build 21.0-b17, mixed mode)

normal fib
11.765000   0.000000 11.765000 ( 11.748000)
11.765000   0.000000 11.765000 ( 11.765000)
11.746000   0.000000 11.746000 ( 11.746000)
11.745000   0.000000 11.745000 ( 11.745000)
11.702000   0.000000 11.702000 ( 11.702000)
fib with constants
14.879000   0.000000 14.879000 ( 14.879000)
14.912000   0.000000 14.912000 ( 14.912000)
15.255000   0.000000 15.255000 ( 15.255000)
15.168000   0.000000 15.168000 ( 15.169000)
15.320000   0.000000 15.320000 ( 15.320000)
fib with additional calls
25.799000   0.000000 25.799000 ( 25.798000)
25.705000   0.000000 25.705000 ( 25.705000)
26.044000   0.000000 26.044000 ( 26.044000)
26.028000   0.000000 26.028000 ( 26.028000)
26.351000   0.000000 26.351000 ( 26.351000)
fib with constants and additional calls
25.053000   0.000000 25.053000 ( 25.053000)
24.406000   0.000000 24.406000 ( 24.406000)
24.550000   0.000000 24.550000 ( 24.550000)
24.478000   0.000000 24.478000 ( 24.478000)
24.381000   0.000000 24.381000 ( 24.381000)

intelsdv07:~/mlvm/jruby$ jruby -J-showversion --client -Xcompile.invokedynamic=false bench/bench_fib_complex.rb 5 35
java version "1.7.0"
Java(TM) SE Runtime Environment (build 1.7.0-b147)
Java HotSpot(TM) Client VM (build 21.0-b17, mixed mode)

normal fib
1.778000   0.000000   1.778000 ( 1.724000)
1.740000   0.000000   1.740000 ( 1.740000)
1.734000   0.000000   1.734000 ( 1.734000)
1.735000   0.000000   1.735000 ( 1.736000)
1.745000   0.000000   1.745000 ( 1.745000)
fib with constants
3.420000   0.000000   3.420000 ( 3.420000)
3.379000   0.000000   3.379000 ( 3.379000)
3.387000   0.000000   3.387000 ( 3.387000)
3.398000   0.000000   3.398000 ( 3.398000)
3.389000   0.000000   3.389000 ( 3.389000)
fib with additional calls
2.953000   0.000000   2.953000 ( 2.953000)
2.973000   0.000000   2.973000 ( 2.973000)
2.974000   0.000000   2.974000 ( 2.974000)
2.977000   0.000000   2.977000 ( 2.977000)
2.979000   0.000000   2.979000 ( 2.979000)
fib with constants and additional calls
4.290000   0.000000   4.290000 ( 4.290000)
4.222000   0.000000   4.222000 ( 4.222000)
4.221000   0.000000   4.221000 ( 4.222000)
4.223000   0.000000   4.223000 ( 4.223000)
4.222000   0.000000   4.222000 ( 4.221000)

intelsdv07:~/mlvm/jruby$ jruby -J-showversion --client bench/bench_fib_complex.rb 5 35
java version "1.8.0-ea"
Java(TM) SE Runtime Environment (build 1.8.0-ea-b01)
Java HotSpot(TM) Client VM (build 22.0-b01-internal, mixed mode)

normal fib
1.072000   0.000000   1.072000 ( 1.056000)
1.059000   0.000000   1.059000 ( 1.059000)
1.042000   0.000000   1.042000 ( 1.042000)
1.043000   0.000000   1.043000 ( 1.044000)
1.048000   0.000000   1.048000 ( 1.049000)
fib with constants
3.178000   0.000000   3.178000 ( 3.179000)
3.036000   0.000000   3.036000 ( 3.036000)
3.056000   0.000000   3.056000 ( 3.056000)
3.052000   0.000000   3.052000 ( 3.052000)
3.052000   0.000000   3.052000 ( 3.052000)
fib with additional calls
1.698000   0.000000   1.698000 ( 1.698000)
1.677000   0.000000   1.677000 ( 1.677000)
1.677000   0.000000   1.677000 ( 1.677000)
1.678000   0.000000   1.678000 ( 1.678000)
1.680000   0.000000   1.680000 ( 1.680000)
fib with constants and additional calls
3.483000   0.000000   3.483000 ( 3.483000)
3.501000   0.000000   3.501000 ( 3.501000)
3.496000   0.000000   3.496000 ( 3.496000)
3.498000   0.000000   3.498000 ( 3.498000)
3.530000   0.000000   3.530000 ( 3.530000)

And here are some numbers for the Red Black Tree benchmark:

intelsdv07:~/mlvm/redblack$ jruby -J-showversion --client bm1.rb
java version "1.7.0"
Java(TM) SE Runtime Environment (build 1.7.0-b147)
Java HotSpot(TM) Client VM (build 21.0-b17, mixed mode)

18.136
17.942
17.969
17.783
17.916

intelsdv07:~/mlvm/redblack$ jruby -J-showversion --client -Xcompile.invokedynamic=false bm1.rb
java version "1.7.0"
Java(TM) SE Runtime Environment (build 1.7.0-b147)
Java HotSpot(TM) Client VM (build 21.0-b17, mixed mode)

2.791
2.563
2.587
2.568
2.628

intelsdv07:~/mlvm/redblack$ jruby -J-showversion --client bm1.rb
java version "1.8.0-ea"
Java(TM) SE Runtime Environment (build 1.8.0-ea-b01)
Java HotSpot(TM) Client VM (build 22.0-b01-internal, mixed mode)

3.998
2.278
2.25
2.204
2.193

JSR 292 SPARC C1 and C2 support

Wed, 7 Apr 2010 13:09:44 GMT

I just pushed the SPARC C1 and C2 patches to support JSR 292 to the MLVM repository. I've tested both thoroughly with JRuby's tests and benchmarks and both work pretty good. Although I know of one bug in C1 this can be treated as the final versions and I'll start the first review round soon to get them into JDK 7 builds.

First invokedynamic call on SPARC

Thu, 25 Feb 2010 13:12:45 GMT

Today I successfully executed an invokedynamic call on SPARC for the first time. Excellent!

$ bin/jruby.gamma -J-XX:+UseSerialGC -J-Djruby.compile.invokedynamic=true -J-Xint -J-XX:+UnlockExperimentalVMOptions -J-XX:+EnableMethodHandles -J-XX:+EnableInvokeDynamic bench/bench_fib_recursive.rb 
OpenJDK Server VM (17.0-b08-internal-jvmg) for solaris-sparc JRE (1.7.0), built on Feb 25 2010 04:35:47 by "ct232829" with Workshop 5.9
VM option '+UseSerialGC'
VM option '+UnlockExperimentalVMOptions'
VM option '+EnableMethodHandles'
VM option '+EnableInvokeDynamic'
 52.813000   0.000000  52.813000 ( 52.296000)
 52.824000   0.000000  52.824000 ( 52.823000)
 51.808000   0.000000  51.808000 ( 51.808000)
 49.740000   0.000000  49.740000 ( 49.740000)
 49.450000   0.000000  49.450000 ( 49.450000)

MethodHandle calls already work since a couple of days and I can run the JDK MethodHandlesTest without any errors:

$ gamma -Xinternalversion
OpenJDK Server VM (17.0-b08-internal-jvmg) for solaris-sparc JRE (1.7.0), built on Feb 25 2010 04:35:47 by "ct232829" with Workshop 5.9
$ gamma -Xint -XX:+UnlockExperimentalVMOptions -XX:+EnableMethodHandles -classpath /java/devtools/share/junit/latest/junit.jar:. org.junit.runner.JUnitCore MethodHandlesTestVM option '+UnlockExperimentalVMOptions'
VM option '+EnableMethodHandles'
JUnit version 4.4
OpenJDK Server VM warning: JSR 292 invokedynamic is disabled in this JVM.  Use -XX:+UnlockExperimentalVMOptions -XX:+EnableInvokeDynamic to enable.
.IIIIII.findStatic
:::::::::::.findVirtual
:::::::::::::::.findSpecial
::.bind
::::::::::::::::::::::.unreflect
::::::::::::::::::::::::I.unreflectGetter
.unreflectSetter
.arrayElementGetter
.arrayElementSetter
.convertArguments
::::::.permuteArguments
.spreadArguments
.collectArguments
.insertArguments
.filterArguments
.foldArguments
.dropArguments
.exactInvoker, genericInvoker, varargsInvoker, dynamicInvoker
.guardWithTest
.catchException
.throwException
.testCastFailure

Time: 7.984

OK (23 tests)

JSR 292 SPARC support is on its way...

JSR 292 server compiler support in JDK 7 b80

Fri, 22 Jan 2010 14:13:19 GMT

About two weeks ago I pushed the remaining changes (6894206, 6893081, 6829187, 6893268) for C2 invokedynamic support on x86 which were integrated into HotSpot 17 b07. Meanwhile HS17b07 has been integrated into JDK 7 b80 and the latter has been released.

With two changesets John Rose pushed lately (6891770, 6914665), which have been integrated into JDK 7 b79, you can run now invokedynamic enabled programs with decent performance. Additionally we tuned inlining heuristics a little (6912063) to be able to use inline-related switches in a product VM and to not count generated MethodHandle adapters.

And here is how it works (gwt is a simple testcase for guardWithTest):

$ java -server -XX:+UnlockExperimentalVMOptions -XX:+EnableMethodHandles -XX:+EnableInvokeDynamic gwt
370655678

You can also run JRuby benchmarks, like bench_fractal.rb which prints a nice fractal (we need to tune inlining heuristics a little to get good performance):

$ bin/jruby --server -J-Djruby.compile.invokedynamic=true -J-XX:+UnlockExperimentalVMOptions -J-XX:+EnableMethodHandles -J-XX:+EnableInvokeDynamic -J-XX:InlineSmallCode=2500 -J-XX:MaxInlineSize=50 bench/bench_fractal.rb
Rendering
<snip>

(To see the fractal you have to try it yourself :-)

The next thing will be C1 support. I'm currently working on it and it's almost finished.

One

Tue, 12 Jan 2010 10:09:30 GMT

It's exactly one year ago that I started to work for Sun. Nice! I wasn't sure that I will make the anniversary facing the merger with Oracle. Anyway, I learned a lot in this first year and I'm really looking forward to the next years at Sun (or whatever the company will be called then).

Compiz and the Meta key in Emacs

Fri, 2 Oct 2009 16:12:48 GMT

When I switched back to OpenSolaris I wanted to use Compiz instead of Metacity to have at least some eye candy. After switching to Compiz I noticed that the Meta key is not working in Emacs. Since it worked in the "Normal Visual Effects" mode I was sure it's related to one of the Compiz plugins that was turned on by default in the "Custom" mode.

After some trial and error I found out that the "Group and Tab Windows" in the "Window Management" section is the bugger. It uses a couple of <Mod4> key bindings and one of them is <Mod4>x.

Disabling that plugin makes M-x work again in Emacs.

Back to OpenSolaris (and DBX)

Fri, 2 Oct 2009 16:12:48 GMT

A few months ago I got a new laptop (unibody MacBook Pro) and I decided to stay with Mac OS X because of two main reasons: Broadcom WiFi and the touchpad. Everything looked very slick and worked, obviously, out-of-the-box. A perfect OS for private use.

But developing on that OS is a pain in the... Apple's GDB drives me nuts! It was crashing every now and then and was 95% of the time not able to call simple C++ instance methods. Completely useless!!!

I filed a few bugs in Apple's Radar and tried to get the FSF guys to support Darwin in their GDB. Some help in both cases, but nothing I could really use.

So, yesterday I decided to bite the bullet, install OpenSolaris again, use NDIS Wrapper for the Broadcom WiFi and to give the xorg-input-synaptics package of SFE a try for the touchpad. The first one is working flawlessly, but only in 32-bit mode. That means I can't test 64-bit HotSpot locally. Well, I can live with that for some time. I didn't have time to try the second one yet but I hope it works.

Glad to be back.

JSR 292 work update

Wed, 9 Sep 2009 13:11:33 GMT

I'm still working on HotSpot compiler support for JSR 292. The progress is actually very good and inlining is already working in C2. Although there are still some problems with scavenging oops in nmethods and you have to stick to UseSerialGC if you want to give it a try. But John Rose is working on a fix for that.

While not working on inlining I started porting JSR 292 support to x86_64. I've already commited the interpreter support and compiler support is in the works and almost finished.

In the meantime Charles Nutter introduced another dynamic language, called Surinx, which uses invokedynamic and "the solid performance of Surinx bodes very well for JRuby's future." That sounds good.

Turning off format=flowed in Thunderbird

Fri, 3 Jul 2009 10:15:48 GMT

I just noticed that I'm sending emails with format=flowed in Thunderbird, which is not intentional. A quick search revealed that both sending and displaying emails in flowed format can be turned off. Just change the following preferences to:

mailnews.display.disable_format_flowed_support = true
mailnews.send_plaintext_flowed = false

Better.

More bit-twiddling intrinsics

Thu, 7 May 2009 11:11:43 GMT

Today I pushed the changes for 6823354 which adds intrinsics for {Integer,Long}.{numberOfLeadingZeros,numberOfTrailingZeros}() methods. The speedups are quite good:

		Integer		Long
		numberOfLeadingZeros	numberOfTrailingZeros	numberOfLeadingZeros	numberOfTrailingZeros
Intel Nehalem	32-bit	3.18	3.96	1.36	1.90
Intel Nehalem	64-bit	3.83	3.74	2.02	2.17
AMD Shanghai	32-bit	1.94	3.55	0.98	2.44
	32-bit w/ lzcnt	4.90	-	1.46	-
	64-bit	2.52	3.09	1.86	3.26
	64-bit w/ lzcnt	6.77	-	3.71	-
UltraSparc T2	32/64-bit	2.01	2.22	1.55	1.91

"w/ lzcnt" in the table means the numbers are using AMD's LZCNT (count leading zeros) instruction which is part of SSE4a.

The SPARC intrinsics need a hardware implementation of the POPC instruction.

Yet I haven't found a real-world application that uses these methods extensively (including bitCount), but if anyone knows one, please let me know.