Yesterday I finished my zero bugs, so now I’m back on Shark. Until a couple of weeks ago I’d been implementing bytecodes one by one as they came up, but during some team meetings I had the idea to cause unimplemented bytecodes to abort only that particular compilation. Previously this would abort the entire VM, but now that I have a fair few of the most common ones implemented already this change would mean Shark was usable even in it’s unfinished state, both for general use and for a little bit of benchmarking. Getting day-to-day grind of implementing bytecodes out of the way means I now need to figure out some of the bigger design issues, however.
One that’s been lurking in the background since pretty much day one is the framewalker stuff. There are all kinds of different types of stack frames in HotSpot, but the relevant ones here are interpreted frames and native frames. Each method in the stack will have one or the other of these*, and it’s one of the cpu-specific code’s jobs to provide accessors into the ABI stack frames so that HotSpot can poke around in them. In the very first days of Shark I tried to make Shark frames appear as native frames, but doing that required all kinds of things I couldn’t provide: PCs and such like. I put in some pretty nasty hacks to make Shark frames look like interpreter frames and got on with the rest of it.
Fast forward a couple of months and this approach is showing the strain. I’m at a bit where the garbage collector is interrogating frames, and the GC needs a lot more than just a method pointer and a BCI. I’m faced with the decision of either trying to store everything into the Shark frames that the C++ interpreter stores (in which case I may as well make them identical, and do away with the distinction) or have another go at implementing Shark frames as native frames.
My gut feeling is to have another go with native frames. Making them interpreter frames is hacky enough, and trying to mimic the C++ interpreter perfectly feels too horrible to contemplate. What I may do first, however, is implement synchronization. It should be possible to handle it without having to resize frames, but it’s not obvious how to extract the number of monitors from the typeflow information so I’ve been avoiding thinking about it. Once I have that done, everything that Shark needs to store will be stored, and I can add the extra stuff to mimic HotSpot’s interpreter/native frames at my leisure.
* This is a simplification, but it’s certainly true of zero as it stands today.
