6354181 and the SystemDictionary

[Tom Rodriguez]

I've been debugging 6354181 where we attempt to initialize a class which is only in the allocated state and die.  After heading off into the weeds for a while I discovered that the problem is that the compiler is finding an instanceKlass which is only in the allocated state instead of in the loaded state and generating code using that klass.  We manage to run the code before the klass has been moved to the loaded state and we end up dying.

I can see several ways to guard against this but I can't decide whether this is something that should be guarded against within SystemDictionary itself or whether users of SystemDictionary should be guarding against it.  It appears that we're finding the class through   SystemDictionary::find_constrained_instance_or_array_klass by going through the loader constraints.  I'm assuming that the klass gets added to the loader constraints early and then gets added into the dictionary proper and marked as loaded which creates the window where things can go wrong.  I also assume that other interfaces that perform lookups would never return a class which was still in the allocated state.

It isn't that hard to reproduce this failure but it's very hard to capture a snap shot of exactly how the dictionary is being manipulated at the time we find the klass which leaves me a little unsure how many places really need to guard against this.  Does this seem plausible to anyone who understands the SystemDictionary?  I believe the proper fix is to add a  guard to SystemDictionary::find_constrained_instance_or_array_klass to only return classes which are really in the loaded state.

Part of the problem here is that ciObject has a base method is_loaded() which returns true if the ciObject is backed by a real Java object.  This means that is_loaded on a ciInstanceKlass doesn't mean the same thing as instanceKlass::is_loaded unless we disallow the allocated state completely.  I could simply guard against it in the CI but that doesn't really feel right.  I will definitely put some asserts about in there though since that would have made the bug much more obvious.

tom