It looks like I have hit one of the gumption traps mentioned in ZMM in my work on Vajra. I don't know how to classify this trap, so I'll just state the problem. The value of a data member of one of the internal objects has gotten changed mysteriously, so to speak. The value is fine during the execution of one bytecode instruction, but gets screwed up somewhere down the line. Ideally, I would get a fix on this by setting a conditional breakpoint, but this is not possible in this case because I don't know how to refer to the object (it exists as a newly added member in a map).

To solve this problem and others of a similar nature, I need a mechanism to track the changes to the VM (the currently executing method and its frame identifier, the bytecode instruction, the pre- and post images of the operand stack, and so on). This requires quite a lot of grunt work (AOP would really come in handy here if I could apply it), which leads to another gumption trap -- boredom.