Another example: if MyClass is the only class that implements MyInterface, HotSpot can generate code that takes advantage of that assumption, removing vtable indirection in method-calls. If, later in the program's execution, the Java classloader loads another class which implements MyInterface, HotSpot will detect that the assumption it made earlier no longer holds. Having determined that the code it generated earlier is no longer safe, it will discard that code.

I recall reading that in earlier versions of HotSpot, it was sometimes possible to improve performance by making your class 'final', enabling the JVM to remove indirection for method-calls. This is not true of the later versions of HotSpot, where it can use the technique described above to safely make optimisations based on tentative assumptions, giving you the same enhanced performance either way.