gbenson.net

I flipped out yesterday and converted my memo-list coping strategy into actual code.

One thing I keep meaning to mention and forgetting. I’m using IcedTea’s bootstrap JDK and plug replacements for my PPC builds:

hg clone http://icedtea.classpath.org/hg/icedtea
cd icedtea
./configure
make boot plugs

The tricky bit is if you want to build 64-bit. I couldn’t decide on the best way to set the data model — integrating setarch and ARCH_DATA_MODEL and who knows what else — so I deferred that particular decision. I made it so that IcedTea always builds 32-bit on ppc and s390, which means you need to symlink the libraries if you want to build with ARCH_DATA_MODEL=64:

ln -s ppc bootstrap/jdk1.7.0/jre/lib/ppc64

I should figure this out properly but it’s hardly urgent.

Long time no post. I haven’t been sleeping well this past couple of weeks so my brain is like sponge. I’ve been filling in stubs, but somewhat slowly, for I’m tired and keep making stupid mistakes. The stubs just say Unimplemented(), which should be printing little file:line error messages, but what’s happening is the the printing code is itself calling Unimplemented() so it’s segfaulting and I have to run it in the debugger every time to see what’s missing. It’s really boring.

Some of the code I’m writing is really nasty*. Thing is, any one of these stubs could take me a week to write, and I don’t want to spend a week writing this and a week writing that and so on and so on. I’d much rather have a load of hacky awful code so I can say “this and this and this need writing, which will take me X many weeks (maybe)”. I don’t like this whole open-ended thing where there’s no way to gauge how close you are to finishing.

The segfault I was debugging the other day turned out a stack overflow caused by the Unimplemented() in Atomic::cmpxchg_ptr (void *, void *, void *) calling itself to generate the error message for the Unimplemented() in Atomic::xchg (jint, jint *). I guess this means it’s time to start writing assembler.

I had a little tangent yesterday while I tried to figure out what sizes all the different types were. aph and mjw pointed me at some stuff [1, 2 and 3]. Who knew?

I fixed the build on ppc64 while I was experimenting too.

Here’s a fun thing: all the commands in OpenJDK will execve() themselves to set LD_LIBRARY_PATH if it’s not what they want it to be. This totally unhooks your gdb session.

Here’s another fun thing: setting _JAVA_LAUNCHER_DEBUG=1 prints out a load of stuff so you can see this bit of tomfoolery. I added an extra bit of debugging in my repository, a dump of the environment so I can see what I need to be exporting to keep gdb hooked in.

Om Shanti.

Not much to report today, other than that I’ve switched from my weird half-IcedTea, half-IBM build environment to using entirely IcedTea. It felt like I was storing up some future hell for myself. Mostly I’ve been trying to figure out how to integrate my porting work into IcedTea so I can get it into a public repository.

I always plan to write about what I’ve been doing at the end of the day, but I never quite get round to it. Usually my head is too full of code, or something. So I end up with a piece of paper with scribble all over it to write about in the morning. Here’s yesterday’s notes.

1. There are two VMs, client and server. When you build the C++ interpreter it’s the server JIT it gets built into.
2. The templater that makes the stubs has some magic to support multi-model architectures. It works like this. To generate the stubs for ppc and ppc64 you run the templater like this:

   python porter/generate.py ppc

   Whether a ppc64-specific file is generated depends on a template’s filename. If it has CPU in it, you get ppc only; if it has CPUS you get ppc and ppc64. So from the template:

   porter/hotspot/src/cpu/CPU/vm/assembler_CPU.cpp

   you get:

   hotspot/src/cpu/ppc/vm/assembler_ppc.hpp

   but from the template:

   porter/hotspot/build/linux/makefiles/CPUS.make

   you get:

   hotspot/build/linux/makefiles/ppc.make
   hotspot/build/linux/makefiles/ppc64.make

   It’s clunky but it works.

3. This is possibly obvious, but sneaky too. Everything in a CPU template is evaluated once, for the main cpu (the one you specify on the command line). A consequence of this is that the templater function is64bit(cpu) will always return False if it’s in a CPU template. You need to use other methods to conditionalize this, #ifdef _LP64 for example.
4. My bootstrap environment is… interesting. XSLT with IcedTea’s gij/ecj combo produces mangled jvmti headers on ppc, but the IBM JDK from RHEL5 doesn’t understand version 50 class files. So I’m using the IBM JDK with IcedTea’s javac wrapper.

Ok, I just saw this:“Note that ARCH_DATA_MODEL is really only needed on Solaris to indicate you want to built the 64-bit version. And before the Solaris 64-bit binaries can be used, they must be merged with the binaries from a separate 32-bit build. The merged binaries may then be used in either 32-bit or 64-bit mode, with the selection occurring at runtime with the -d32 or -d64 options.”

I was away all last week on a training course where I caught a cold despite sneaking off between labs for yoga breaks. Now I’m sat here feeling like death and trying to figure out where I left off.

Ok, where I left off was that I finally made enough stubs for the build to finish building Hotspot and to start failing on the class library instead. I had been about to throw myself into the class library failures, but I found out that ppc64 is not the sleek modern version of ppc but rather its fat ugly sister so I rearranged the build system to favour ppc instead.

It’s quite neat. There’s an environment variable, ARCH_DATA_MODEL, which allows 32-bit VMs to be built on amd64 and 64-bit VMs to be built on sparc. It flips ARCH — though not everywhere! — to i486 (on amd64 with ARCH_DATA_MODEL=32) and to sparcv9 (on sparc with ARCH_DATA_MODEL=64). I think it’s only used on Solaris at present, but the best bit for me is that there is no sparcv9 directory — it shares with sparc. I fixed it so ppc/ppc64 and s390/s390x do the same thing, so you’ll get a ppc64/s390x build if you set ARCH_DATA_MODEL=64 and a ppc/s390 build otherwise. So now I only have three sets of stubs to worry about, not five.