De-opt support and dependency tracking in HotSpot

Douglas Simon doug.simon at
Wed Sep 22 08:20:39 PDT 2010


We are currently implementing de-opt support in the Maxine VM. I've just spent some time browsing HotSpot source code to see how dependencies are tracked for the purpose of speculative opts and de-opt. A very brief summary of what I've deduced is below. Any corrections/feedback/pointers to (non-code-embedded) documentation on this part of HotSpot would be greatly appreciated!


Dependency tracking in HotSpot

A dependency is from a compiled method (i.e. nmethod) to a class (i.e. a klass). A dependency may be actually to specific method in a class but for the purpose of triggering dependency checking, it is the class in a dependency that matters. A compiled method can have more than one dependency and so each compiled method encodes a set of dependencies. A dependency is essentially a <DepType, klass> pair. For example, <concrete_with_no_concrete_subtype, java.util.HashMap>. When a new class is loaded, it is the root of a "dependency change set" (i.e. a DepChange) which is the super class hierarchy (including interfaces) rooted by the new class. The set of (live) compiled methods in the code cache is traversed just before the new class is registered in the system dictionary to see if any of them has a dependency in the dependency change set. If so and the assumption represented by the dependency is invalidated, then de-opt is triggered for the nmethod.

A potentially significant cost in this mechanism is the traversal of all methods in the code cache for each new class loaded. I assume this is done under the code cache lock. It may be that the cost of this in HotSpot is actually not so high as the number of nmethods code cache is relatively small (HotSpot has an interpreter). And it may also be mitigated by the fact that the cost of class loading dwarfs the cost of code cache traversals.

More information about the hotspot-dev mailing list