[kaffe] completed bytecode verifier!
robilad at kaffe.org
Fri Aug 8 06:37:02 PDT 2003
Helmer Krämer wrote:
> If you try running $JAVA at.dms.kjc.CSourceClass afterwards,
> you will see that kaffe thinks that it has detected a
> Now comes the confusing part, since I'll try to explain what
> I think is going on here ;)
> First of all, CSourceClass is derived from CClass, which is derived
> from CMember (all in package at.dms.kjc). So when kaffe has to load
> CSourceClass, that will trigger loading CClass and loading CClass in
> turn will trigger loading CMember. This will cause kaffe to process
> CMember to state CSTATE_LINKED, while CSourceClass and CClass are
> both in the CSTATE_LOADED_SUPER state (and their classMappingState
> is NMS_LOADING).
> Processing CMember to CSTATE_LINKED however, includes verifcation
> of the class CMember (both, verify2 and verify3). But in order to
> do this, the verifier has to resolve the types CSourceClass and
> CClass (they are needed for type checking during verification of
> the getAccessorOwner method). Since the verifier uses loadClass()
> to resolve the type, the ClassCircularityError is thrown (because
> classMappingSearch detects that the state is NMS_LOADING and that
> the current thread is responsible for it).
This seems to be a similar chicken-and-egg type of problem one's facing
during class loading. That seems to have been solved by introducing some
new CSTATES, like CSTATE_DOING_something and NMS states like NMS_*ING.
Would a similar solution be appropriate for this problem?
More information about the kaffe