Older blog entries for twisti (starting at number 28)

7 May 2009 (updated 7 May 2011 at 06:17 UTC) »

More bit-twiddling intrinsics

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

Syndicated 2009-05-07 11:03:50 (Updated 2009-05-07 18:10:47) from twisti's weblog

17 Apr 2009 (updated 7 May 2011 at 06:17 UTC) »

A lot of changes need a lot of testing

I'm still working on adding an AddressLiteral class on SPARC (6822110) to actually finish the load shortening optimizations (6814842) and to remove useless I2L conversions (5057225).  But 6822110 became really huge and it needs a lot of testing.  I hope I can push it next week.

Syndicated 2009-04-17 11:49:27 (Updated 2009-04-17 18:49:27) from twisti's weblog

1 Mar 2009 (updated 7 May 2011 at 06:17 UTC) »

Skype on Solaris

[It almost took me a full day to get it working, so I will write down what I have done to get there.]

Actually I wanted to use Ekiga, but it does not work very well in OpenSolaris and not many "normal" (reads: non-geek) people use such clients.  And I wanted to reach some of my "normal" friends, which almost all are using Windows and most possibly Skype.

Maybe there will be a native OpenSolaris port of Skype someday, but for now we have to go different ways.

You can use the "seamless mode" from VirtualBox to run Skype on Windows.  Feature-wise this is probably the best solution, but you need to install Windows (not an option for me).  And I'm not 100% sure that sound will work in VirtualBox as it always complained about problems opening some PCM devices.

Instead of using Windows  you could use Ubuntu to run Skype and there is the possibility of transferring the install into a BrandZ Linux zone.  And that's what I wanted to do.

First of all I tried the CentOS 3 image from here, but it's too old to run a recent Skype and it is really hard to find older versions on the web (well, I found one but I couldn't get it working).

Then I tried to install Ubuntu 8.04 and CentOS 5 in VirtualBox, but both was so slow that I canceled that and searched for CentOS image tar's instead.  Fortunately I found this site where you can download CentOS 4 and 5 images as tar files.

So I installed CentOS 5 in a zone and that worked perfectly.  But when I wanted to start Skype I got this error.  Seems like it's a known problem and not related to zones.

Then CentOS 4... yeah... GCC C++ ABI problems.  Skype wants 3.4.4, but CentOS only has 3.4.3.

So... what else is left?  Debian.  And I wanted to get it running in a zone...

I downloaded a businesscard install image, because it's the smallest one (32M), and installed the smallest possible system in VirtualBox.  That install was actually very fast.  Then got Skype for Debian, scp'ed it into the VirtualBox, installed all required packages (don't forget xbase-clients for SSH X11 forwarding), tar'ed up the whole root filesystem, scp'ed the image back to the native system and installed it into a zone.  The zone install does not work out-of-the-box, obviously Debian is not RHEL or CentOS, so I hacked it a bit.

Execute the following commands in VirtualBox before you tar up the whole filesystem:

$ mkdir /etc/sysconfig
$ mkdir /etc/rc.d
$ touch /etc/rc.d/rc.sysinit

and the zone install will be successful.

[I have to add here that the Debian zone does not boot properly (try zlogin -C), so it would be better to get it working in CentOS 5, but that doesn't really matter.  Log into the zone with zlogin and start the SSH daemon.]

Then I logged into the zone via SSH (only root works, as can be read here too) and started Skype...

WOOHOO!

It came up and signed in successfully!  Chat worked, calls didn't.

This is because BrandZ only maps OSS and the Skype Debian version uses ALSA. But hey, that last hurdle must be cleared too, right?

So, simply download the static OSS version of Skype and use that one...

Voila!  Skype calls on OpenSolaris!

Easy, wasn't it?

Syndicated 2009-03-01 18:19:47 (Updated 2009-03-02 02:19:47) from twisti's weblog

3 Feb 2009 (updated 7 May 2011 at 06:17 UTC) »

My first bugfix

Today I pushed my first bugfix.  To be honest, I had a little help from Tom Rodriguez who pointed me to the right function.  I hope someday the time will come when I can help you, Tom :-)

Syndicated 2009-02-03 15:07:35 (Updated 2009-02-03 23:07:35) from twisti's weblog

28 Jan 2009 (updated 7 May 2011 at 06:17 UTC) »

My first commit

Yesterday I was able, after some trouble with Mercurial queues, to push my first commit to the HotSpot repository.  The changeset is actually uninspiring but hey, it's my first one!

Syndicated 2009-01-28 09:51:24 (Updated 2009-01-28 17:51:24) from twisti's weblog

14 Jan 2009 (updated 7 May 2011 at 06:17 UTC) »

Into the Sun

Those of you who have wondered what I will do in the future: I'm now part of the HotSpot team at Sun Microsystems and I will work on the C2 (server) compiler.

Actually today is my third day but only now my account is working.  I'm really looking forward to tackle the challenges that will come up.

And as I always said, I will not leave the Free Java Community...

Syndicated 2009-01-14 16:39:39 (Updated 2009-01-15 00:39:39) from twisti's weblog

Goodbye...

1. ...Random

For the last two and a half years I played in a punkrock band called Random and in autumn last year we decided to quit (farewell letter is in german, sorry).

There were different reasons for this decision, but mostly personal ones. Our singer opened his own restaurant in my hometown Linz (give him a visit when you are there, it's a great place) and I got sick about traveling every weekend from Vienna to Linz for rehearsal.

Anyway, it was a great time and I don't want to miss it! Thank you guys!

If you want to get a piece of that time, try to get a copy of our latest CD or download the songs from various download platforms.

2. ...CACAO

Also last autumn I quit my job at Theobroma Systems where I worked full-time on CACAO. Again, there were different reasons for my retirement.

I started my work on CACAO during my computer science studies at the Vienna University of Technology with a practical course about an i386 backend for the JIT compiler. My diploma thesis ("Optimizing and Porting the CACAO JVM") was about a x86_64 backend and some class loader optimizations, like eager class loading.

After my thesis I started my Ph.D. in the Christian Doppler Laboratory: Compilation Techniques for Embedded Processors, where I worked on a port of CACAO to a DSP architecture. Unfortunately funding was discontinued and I had to cancel my Ph.D.

Since 2004 I was kind of the "official" maintainer of the CACAO project and since then CACAO matured from a "fast JIT compiler for Java bytecode" to something you can really call a Java Virtual Machine. One big advantage of CACAO is the number of architectures its JIT compiler supports (about 11).

In May 2007 Sun released OpenJDK and I started to implement the HotSpot VM interface in CACAO. I think CACAO was the first non-HotSpot JVM that supported the OpenJDK core library (please correct me if I'm wrong).

Then RedHat launched the IcedTea project and HotSpot got a generic port of the HotSpot C++ interpreter called Zero. The development of Zero pushed me for the first time to think about the future of CACAO and myself. When the official and JCK-tested JVM can run on literally all architectures out there, who will still use CACAO?

Well, the answer is probably: those who want performance.

But RedHat (actually Gary Benson) came up with another very cool thing called Shark. Shark is the answer to the performance problem of Zero: it uses LLVM to do the JIT compilation in a mixed mode. Although it's not finished yet, it will be the main competitor for CACAO when it comes to decide which JVM you should use on your non-HotSpot architecture. Shark pushed me for the second time to think about the future of CACAO and myself...

Mostly for these reasons and since I always wanted to integrate an optimizing compiler in CACAO and implement mature optimizations in this compiler, but it seemed there is not enough time for a single person to do that, I decided to quit at Theobroma Systems and to quit my work on and maintainership of CACAO.

In the meantime Michael Starzinger will take the maintainership of CACAO. He's a long-time contributor and he knows a lot of the CACAO system. He's the right person for this job.

For me, hopefully a new and challenging opportunity will open up where I can work on the things I always liked to in the past few years. I will let you know...

Right-mouse on a MacBook Pro

I've got a new, shiny MackBook Pro (actually an old one like this but with 15", because I don't like the new ones) and, as probably everyone knows: it only has one button. That sucks very much when it comes to context menus. On my old PowerBook G4 I had some settings in my xorg.conf to enable two- and three-finger taps, but I don't wanted to do that again.

Instead I wanted something to be turned on in GNOME itself. So my attention came to accessibility extensions.

Fortunately I don't need them but there is a nice mouse feature called "Simulated Secondary Click". I wanted to turn on "Trigger secondary click by holding down the primary button", but it said something about "mousetweaks is not installed". Damn...

I searched the OpenSolaris package repositories but couldn't find it. I thought this is a GNOME core package? And what about handicapped people really needing this? So I searched in the spec-files and found this as comment in SUNWgnome-a11y-mousetweaks:


# We have removed mousetweaks from our builds since it is GPLv3.
# For now, leave in the following comment so that our ARC
scripts
# recognize that we are not shipping this module starting with
# the 2.24 release.  When we re-integrate this package, remove
# the following line:
# PACKAGE NOT ARC REVIEWED BY SUN JDS TEAM

I have also filed a bug report to see what the exact problem is.

In the meantime I built it myself from source. I downloaded JDS Common Build Environment (CBE), patched the spec-file a bit:


Index: SUNWgnome-a11y-mousetweaks.spec
===================================================================
--- SUNWgnome-a11y-mousetweaks.spec	(revision 16491)
+++ SUNWgnome-a11y-mousetweaks.spec	(working copy)
@@ -23,7 +23,7 @@
 Name:                    SUNWgnome-a11y-mousetweaks
 Summary:                 provided mouse accessibility
enhancements
 Version:                 %{mousetweaks.version}
-Source:                  %{name}-manpages-0.1.tar.gz
+#Source:                  %{name}-manpages-0.1.tar.gz
 SUNW_BaseDir:            %{_basedir}
 SUNW_Copyright:          %{name}.copyright
 BuildRoot:               %{_tmppath}/%{name}-%{version}-build
@@ -79,9 +79,9 @@
 %install
 rm -rf $RPM_BUILD_ROOT
 %mousetweaks.install -d %name-%version
-rm -rf $RPM_BUILD_ROOT%{_mandir}
-cd %{_builddir}/%name-%version/sun-manpages
-make install DESTDIR=$RPM_BUILD_ROOT
+#rm -rf $RPM_BUILD_ROOT%{_mandir}
+#cd %{_builddir}/%name-%version/sun-manpages
+#make install DESTDIR=$RPM_BUILD_ROOT
 
 %if %build_l10n
 %else

...and: voila! I have a right mouse. Nice.

(free) OpenJDK on OpenSolaris, Part 64

After getting the 32-bit IcedTea built, I also want a 64-bit OpenSolaris version. But I can't get over this error:


----------
1. ERROR in
/export/home/twisti/projects/openjdk/icedtea6-bootstrap/build-hotspot-m64/openjdk-ecj/hotspot/agent/src/share/classes/sun/jvm/hotspot/jdi/ConnectorImpl.java
(at line 28)
        import com.sun.tools.jdi.LinkedHashMap;
               ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
The import com.sun.tools.jdi.LinkedHashMap cannot be resolved
----------
1 problem (1 error)make[7]: *** [../generated/sa-jdi.jar]
Error 255

I am absolutely sure I had the same issue with the 32-bit build, but I can't remember how I fixed it. Damn!

So I decided to build OpenJDK directly with my pre-built IcedTea. Again it took some workarounds, but it worked:


$ java -version
openjdk version "1.6.0-internal"
OpenJDK Runtime Environment (build
1.6.0-internal-twisti_19_oct_2008_17_12-b00)
OpenJDK Server VM (build 10.0-b19, mixed mode)

And the actually wanted 64-bit version:


$ java -d64 -version
openjdk version "1.6.0-internal"
OpenJDK Runtime Environment (build
1.6.0-internal-twisti_19_oct_2008_17_12-b00)
OpenJDK 64-Bit Server VM (build 10.0-b19, mixed mode)

Now I will try OpenJDK7.

(free) OpenJDK on OpenSolaris

Today I was able for the first time to build OpenJDK on OpenSolaris completely with free tools. Unfortunately I couldn't use use CACAO as bootstrap VM because Boehm-GC has some problems on OpenSolaris, which I couldn't fix yet.

Since GCJ also uses Boehm-GC, I decided to use JamVM. The port was very straight-forward, except one small getcwd problem for which Robert already had a fix for. I will contribute all JamVM changes back to Robert.

After some IcedTea build system changes (yet to commit), some JVMTI file copying (maybe this is a JamVM bug, see instructions at the end), a small OpenJDK patch and some time, I got:


IcedTea is served: openjdk/control/build/solaris-i586

And, obviously, the build works:


$ uname -a
SunOS workstation 5.11 snv_98 i86pc i386 i86pc Solaris
$ java -version
java version "1.6.0_0"
OpenJDK Runtime Environment (build 1.6.0_0-b12)
OpenJDK Server VM (build 1.6.0_0-b12, mixed mode)

I tried to write down all stuff that needs to be done here, but I'm very sure some steps are missing...

19 older entries...

New Advogato Features

New HTML Parser: The long-awaited libxml2 based HTML parser code is live. It needs further work but already handles most markup better than the original parser.

Keep up with the latest Advogato features by reading the Advogato status blog.

If you're a C programmer with some spare time, take a look at the mod_virgule project page and help us with one of the tasks on the ToDo list!