Concern

Returning to work is kind of kooky, mostly because absolutely nothing happened or changed in the month that I was absent. I didn’t expect much to have changed, but jeez, I mean hardly anyone even checked in any code. I could have just showed up every day and worked on my SoC project; then I wouldn’t have used up any vacation time.

My four-week vacation has come to an end. For the most part, all I did was sleep until noon, sit on my ass, and write code. I can’t personally think of a better way to spend a vacation.

But now, back to work on Monday. I don’t much enjoy having to go back to the ‘Gate, but yeah, I gotta do it.

You know, if we, as a commuting public, are ever to adopt mass transit any more than the little we do now, it really is going to have to improve.

I was going to go to San Francisco today, from Fremont, to see A Scanner Darkly (because it’s only playing there, and not anywhere near this piece of shit town), then go to an art show opening of a friend of my aunt. I’m in south Fremont, so this does mean driving to BART, because south Fremont/Milpitas is a total black hole when it comes to public transit (connecting BART to CalTrain is just too good an idea, I guess). But yeah, there’s no place to park near Fremont BART. Nor anywhere in the three-block radius surrounding it. So I managed to park in some residential area nearby, but hey! It turns out there’s no way to walk from there to BART! I instead got to walk around in a big loop, in the sun, and missed the train.

It’s apparently “spare the air” day, and BART is free today. I guess this is supposed to entice more people to use BART, but all it does is make the experience much worse than it already is: it’s stressing the system (especially the parking systems surrounding the stations) and making BART nearly impossible to use. All this “spare the air” day results in is that I want to drive instead of ever taking the train again. That’s the real reason why public transit isn’t used more: it isn’t as available as it needs to be (I should be able to walk a short distance to a station), it’s unpleasant, and there isn’t enough capacity!

Personal transportation is never going to go away; we can pretend that we can make mass transit work by building out infrastructure and avoiding suburban sprawl, but practically speaking the only way to reliably transport yourself across any distance is to drive.

OK, so I was able to fix some of the stack alignment issues in Cacao on Intel OS X. Now things seem to work if I use soft null pointer checking. It looks like there are still alignment issues with hardware NPE handling, but because GDB sucks so hard I can’t investigate this any further (in OS X GDB, you get Mach traps instead of signals for things like null pointer accesses, and you can’t skip over them when they get signaled).

Edit: I think I’ve worked out some of the kinks (and, a newer GDB actually sucks less, and lets you handle EXC_BAD_ACCESS nostop noprint), so now Cacao works most of the time with hardware NPE support. It still occasionally barfs up a SIGILL when running Mauve, but this is a nice step forward. I’m running it now in GDB to see if it’s still a stack alignment issue.

I took a little time trying to get Cacao to run on x86 OS X again today. Porting the code is relatively easy — some tweaks to support the x86 Darwin signal handling, and some fixes for Darwin’s weird assembler, and it compiles fine. The big problem with getting it to run, however, is still stack alignment. Darwin’s x86 ABI is the same as that on Linux-x86 and FreeBSD-x86, except that the stack must be aligned on a 16-byte boundary. Somewhere in the call stack, however (maybe in the assembly support, maybe in the jitted code or one of the generated trampolines — I’m not certain yet) the stack gets misaligned, and this breaks things badly, eventually.

For the most part, the code will happily run with a misaligned stack; the problem manifests itself when a JNI dynamic symbol is resolved: the _dyld_stub_binding_helper_interface routine loads values from the stack into XMM registers, which will fail with an illegal instruction error if the stack is not properly aligned. So what happens is that the VM bootstrap starts, and runs, but as soon as a JNI method is called with the stack misaligned, the program aborts with SIGILL.

There is some code that tries to align the stack properly here and there, but it clearly isn’t working. Something I’m not sure about is the interaction of the code that tries to keep the stack aligned, and the call/push instructions.