Synchronization

I figured out the deal with getting the number of monitors from typeflow. I was confused because it only tells you the number of monitors at the start of each block, but what I didn’t realise is that it inserts block boundaries after every monitorenter and monitorexit, so the number of monitors remains constant for entire block. A quick scan through a method’s blocks will find the one with the most monitors, and that’s the maximum number of monitors you need for your method. I wrote the code to allocate them yesterday; today I write the code to actually lock and unlock things with them.

As an aside, I’ve seen a few people refer to zero as a VM in its own right, a replacement for HotSpot, but this isn’t the case at all: zero is a port of HotSpot. HotSpot is a largely generic VM with a small number of CPU- and OS-specific files, and when people refer to a port of HotSpot to some processor or operating system, they’re talking about these files. If you look inside an OpenJDK tarball, you’ll find the HotSpot sources in something like these directories:

openjdk/hotspot/src/share
openjdk/hotspot/src/cpu/x86
openjdk/hotspot/src/cpu/sparc
openjdk/hotspot/src/os/linux
openjdk/hotspot/src/os/solaris
openjdk/hotspot/src/os/win32
openjdk/hotspot/src/os_cpu/linux_x86
openjdk/hotspot/src/os_cpu/linux_sparc
openjdk/hotspot/src/os_cpu/solaris_x86
openjdk/hotspot/src/os_cpu/solaris_sparc
openjdk/hotspot/src/os_cpu/win32_x86

Zero adds the following directories to that list:

openjdk/hotspot/src/cpu/zero
openjdk/hotspot/src/os_cpu/linux_zero

So when you build HotSpot with zero, you’re using the following code:

openjdk/hotspot/src/share              444,621 lines
openjdk/hotspot/src/cpu/zero             5,300 lines
openjdk/hotspot/src/os/linux             7,865 lines
openjdk/hotspot/src/os_cpu/linux_zero    1,085 lines

That’s 98.6% pure, unadulterated HotSpot.

(Shark isn’t a VM either: it’s a optional JIT compiler for the zero port of HotSpot.)