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
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:
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.)