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.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.