Older blog entries for twisti (starting at number 20)

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.

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

Two days ago I actually released CACAO 0.99.3, but didn't have time to do the announcement yet. Nonetheless the release has one very cool feature: you can play Jake2 for the first time! Simply run the Jake2 Webstart (I used the jogl-1.1 one) and start fragging.

Here is a screenshot playing it on x86_64-linux:

It should run on other architectures too, I'll try powerpc when I'm back home.

Yesterday I finally was able to finish the OpenJDK build on Alpha Linux. I'm not exactly sure what really fixed the build, but definitely adding the missing compiler flags again (with -D_LITTLE_ENDIAN) helped. When Gary commited his zero work we lost some architecture dependent flags, I'll re-add them ASAP.

And now to the fun:

Pheew! After more than one year our codebase was ready to get a new release... so I did. And then I noticed, because I was a bit out of practice doing a release, it had a few bugs. Yeah, of course :-( So I made another one, called 0.99.1.

With official OpenJDK Java runtime library support we are now heading to a 1.0.0 release. I hope that one will be without bugs...

I wanted to change the default font of Emacs without setting properties in the .Xresources. The window font can be changed with:

M-x customize-face RET default RET

I set it to misc-fixed with height 113.

The menubar font can be changed with:

M-x customize-face RET menu RET

I'm still searching for the correct font, but in my .Xresources it was:

Emacs*menubar.font: Lucida

It took me some time to figure that out, because it's not installed per default from CD and I haven't upgraded the whole system yet (because I'm still running on my swap partition).

It's in SUNWgnome-common-devel. Pheew...

Because I didn't know my WIFI password from the top of my head, I entered the wrong one when nwamd(1) was asking for it. But it didn't ask again. So I wondered where the passwords are stored.

After some google'ing I found the correct command:

# dladm show-secobj

Then I could delete the stored password with:

# dladm delete-secobj nwam-twisti-xx.xx.xx.xx.xx.xx

It seems dladm(1) is just a frontend for text files. The passwords are actually stored in /etc/dladm/secobj.conf.

I'm thinking about to switch to OpenSolaris on my Apple mac mini. I installed Indiana on my Linux swap partition to see how it works.

Right now I'm trying to get suspend working (http://blogs.sun.com/randyf/entry/solaris_suspend_and_resume_how), but I'm not sure it will work with this version:

May 28 21:19:41 workstation genunix: [ID 314293 kern.info]
device pci8086,27a2@2(display#0) keeps up device
sd@0,0(sd#0), but the latter is not power managed

Today I pulled myself together and tried to build IcedTea for ARM again. I had two options: to build it natively on an ARM board or try to cross-compile it. I decided to try the cross-compile approach.

The build did not fully finish, because I don't have ALSA libraries in my cross-build enviroment, so I just took an j2re-image from an x86_64 build and replaced

bin/java

with the cross-compiled one and copied

openjdk/control/build/linux-arm/lib/arm/

into the x86_64 j2re-image.

And it works!!!

$ uname -m
armv5tejl
$ java -version
java version "1.6.0"
IcedTea Runtime Environment (build 1.6.0-b06)
CACAO (build 0.98+svn, JIT mode)

(btw. this output calls 10273 Java methods)

Now I'm testing applications like DaCapo and most benchmarks of DaCapo already pass in small size.