I hate Linux user-space

I made the mistake of upgrading my Powerbook to Fedora 10 yesterday. As I was about to do some Jato hacking today, I noticed that the up arrow key caused Gnome to attempt to take a screenshot. So I googled around, found nothing useful, eventually fiddled around with Xorg config and, of course, hosed X.

I then started messing around with /etc/sysconfig/keyboard (not knowing what I was doing) and hosed my keyboard completely. I eventually figured out how to boot to /bin/sh from yaboot (regular init had the wrong keyboard configuration) and was able to restore console access, fix my Xorg config, and now I'm back to Gnome. (I "only" spent an hour on this.)

Of course, the up arrow key still doesn't work but at least Gnome doesn't attempt to capture the screen now.

Update: Apparently I had changed Xmodmap in Fedora 8 and after reinstalling some xorg components, I have my keyboard in somewhat working state. I'm still missing curly braces so no hacking on this laptop...

Update 2: I ended up adding this small .xmodmap file to my home directory:

    clear mod4
    clear mod4
    add mod5 = Super_L

which effectively makes the Apple/Command key function like Alt-Gr on PC and now I have a fully working keyboard! Yay!

BC2IR

The first step of a modern JIT compiler for the JVM is to convert the stack-based instructions to register-based instructions as all CPUs follow the latter model. While the problem is not new, it's actually quite hard to find relevant literature on the topic.

One of the few algorithms that are documented, is the BC2IR algorithm used by JikesRVM. There's a brief summary of it in Section 5.1 ("The BC2IR Algorithm") of the Jalapeno Dynamic Optimizing Compiler for Java paper and a more extensive description in Section 3.3 of ("Converting from bytecode to IR") John Whaley's master's thesis for those who are interested in the details.

Memory Management

If you're interested in memory management, check out these excellent blog posts with real-world examples by Gustavo Duarte on various memory management topics:

• CPU caches


• CPU/memory interface


• Process virtual address space


• Kernel memory management


• Page cache

Update: Added link to an article on page cache.

Examining assembly generated by HotSpot

HotSpot has the -XX:+PrintAssembly debugging option for dumping generated assembly code of JIT compiled classes but it's not available in regular production builds. Fortunately, tuomask has written a short, straight to the point instructions how to get it working with jdk7 on Ubuntu. Nice!

HotSpot, Zero, and Shark

For those who don't already know about it, Gary Benson has been working for a while now on two HotSpot related projects, Zero and Shark. Zero is a port of HotSpot that does not require any assembly code which means it's easily portable to any machine architecture supported by GCC.

Whereas Zero only supports bytecode interpretation for obvious reasons, Shark, on the other hand, is a port of HotSpot on top of LLVM, the compiler framework. With LLVM, HotSpot JIT can be ported to all the machine architectures LLVM supports. I think Gary is doing this for Red Hat to be able to get a decent version of OpenJDK for the PowerPC platform but, of course, people interested in porting HotSpot to other architectures will also benefit from this.

In an attempt to make contributing to Zero and Shark easier, Gary has written up several blog posts under the title "Inside Zero and Shark." The title is somewhat misleading as the bulk of the posts are actually about HotSpot internals. Here are the posts so far:

• Java threads and state transitions


• Handles and oops, traps and checks


• Calling conventions and the call stub


• The Java stack


• HotSpot’s stacks


• The call stub and the frame manager

They are good read to anyone interested in Hotspot and/or JVM internals.