Re: [kaffe] State of the Verifier
Hi Tim, After looking into backporting the JanosVM design, I've decided to leave the class loading system largely alone, with the exception that loadClass will have a new parameter that allows you to specify to what target state a class should be loaded until. The new method is called loadClassToState, and loadClass simply forwards a call to loadClassToState with the default target state. The reason for this is that, during verification, if I really need to load a class, I don't want to link it (that can cause circular dependency problems when loading on the same thread), but only get it to the point where I can see its superclass. If you can see any problems with this, let me know. Instead of touching the rest of the loader, I'm dealing with lots of string comparrisons of names and type signatures in the verifier. Thus if I don't need to load a class but know its name, I treat it's name as its type. Lots of casts and shit, a little messy, but it gets the job done without messing with the loader. Cheers, Rob I'm just not convinced you need to mess with class loading to do this. There is a lot of complexity and subtlety in loading and I would really like to avoid touching it without good cause. I'm not really talking about any serious modification to class loading. Every change to the loader is serious ;) All that would happen is that the memory allocation of the Hjava_lang_Class instance would happen earlier, allowing me to have a pointer to the class for type checking without loading the actual class. Again, right now the memory allocation is tied to the actual class loading. Everything else would remain as is. One example I can think of is that it might conflict with error handling. At the moment, the loader allows you to reload classes that fail early on, which mimics the behavior of jdk 1.3.1. This might not work anymore if the class pointer has to be stable and can't be replaced for a failed class. There might be other semantic changes that crop up as well... Basically, the only thing I know is that the lookup.c path is much less treacherous than trying to change the loader. ___ kaffe mailing list [EMAIL PROTECTED] http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] State of the Verifier
Hi Tim, Thats cool... As I was thinking about it more, the JanosVM changes are more useful for changes in the jitter than for verifying (Basically, you want to generate code 'optimal' code if the class is loaded, but you don't want to force loading either.) with the exception that loadClass will have a new parameter that allows you to specify to what target state a class should be loaded until. The new method is called loadClassToState, and loadClass simply forwards a call to loadClassToState with the default target state. The reason for this is that, during verification, if I really need to load a class, I don't want to link it (that can cause circular dependency problems when loading on the same thread), I don't understand why this is a problem. Here's why this is a problem during verification. When verify3() is called on a class, the class is CSTATE_PREPARED. Suppose that I am verifying class A and I need to load class B to complete verifying class A. Now, loadClass makes sure a class is processed to CSTATE_LINKED, which is just after verify3() is called. But suppose class B requires class A to be loaded to complete verification. Then loadClass is called, class A is found in memory but it has not yet been processed to CSTATE_LINKED, so the thread tries to verify3() it again. This is legal because it's the same calling thread, so it already has the lock for class A. etc. etc. What I can do instead is to create a new CSTATE_BEING_LINKED or something instead of doing the loadClassToState() method. That probably works...that sound alright? I'm still getting my feet wet in the kaffe core internals, so thanks for helping me out :) Cheers, Rob ___ kaffe mailing list [EMAIL PROTECTED] http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] State of the Verifier
Hi, hi, I don't see why instanceof or checkcast would need to be loaded aggressively during verification, but my hunch is that they're dealing with some of the same issues that I am. Namely, when checkcast is performed during execution simulation you'll need to be able to load a pointer to the class for type checking... I'll drop the JanosVM people a line to clarify this point. Well, I am the JanosVM person ;) Anyways, as I said in the reply, I just never got around to adapting them like the others. But yes, the lazy loading is what I'm trying to accomplish. verify3() is called when a class is about to be linked. At this point, according to the JVM spec you're not supposed to check whether a given class has a given field, or even whether a given class exists _unless_ you need that class for type checking (i.e. if you expect something of type A and have something of type B, then you have to load B to see if A is in its superclass type hierarchy). Can't you just use the signature like in code-analyse.c. Theres already a bunch of code in lookup.c for taking care of this stuff. Not really. The getField() and getClass() and getClassFromSignature() and stuff like that all cause the referenced class to be loaded and, in most cases, linked. The JanosVM versions don't, so you can try backporting those. I'm just not convinced you need to mess with class loading to do this. There is a lot of complexity and subtlety in loading and I would really like to avoid touching it without good cause. I'm not really talking about any serious modification to class loading. Every change to the loader is serious ;) All that would happen is that the memory allocation of the Hjava_lang_Class instance would happen earlier, allowing me to have a pointer to the class for type checking without loading the actual class. Again, right now the memory allocation is tied to the actual class loading. Everything else would remain as is. One example I can think of is that it might conflict with error handling. At the moment, the loader allows you to reload classes that fail early on, which mimics the behavior of jdk 1.3.1. This might not work anymore if the class pointer has to be stable and can't be replaced for a failed class. There might be other semantic changes that crop up as well... Basically, the only thing I know is that the lookup.c path is much less treacherous than trying to change the loader. Maybe I'm not explaining this well or maybe I'm overlooking some complications. Admittedly, I'm certainly not an expert about the class loading system of Kaffe. However, I'm pretty sure what I'm planning on doing isn't going to interfere with anything else, as classes will still be loaded through code-analyze just before they are needed at execution of a method. Should I post a patch that you can look at to better decide whether what I'm doing is a bad idea? Maybe... I could also write some tests to make sure the semantics of the loader aren't being changed. Thanks, Rob tim ___ kaffe mailing list [EMAIL PROTECTED] http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] State of the Verifier
Hello, verify3() is called when a class is about to be linked. At this point, according to the JVM spec you're not supposed to check whether a given class has a given field, or even whether a given class exists _unless_ you need that class for type checking (i.e. if you expect something of type A and have something of type B, then you have to load B to see if A is in its superclass type hierarchy). Can't you just use the signature like in code-analyse.c. Theres already a bunch of code in lookup.c for taking care of this stuff. Not really. The getField() and getClass() and getClassFromSignature() and stuff like that all cause the referenced class to be loaded and, in most cases, linked. The JanosVM versions don't, so you can try backporting those. Are you sure the janosVM versions don't force the referenced class to be linked? I just spent some time poking around the 1.0a source and it seems that they do... of course, I could simply be misreading something. Rob ___ kaffe mailing list [EMAIL PROTECTED] http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] State of the Verifier
Hello, hi, The JanosVM versions don't, so you can try backporting those. Are you sure the janosVM versions don't force the referenced class to be linked? I just spent some time poking around the 1.0a source and it seems that they do... of course, I could simply be misreading something. Do you have example java code or is there any particular code in the VM that looks suspicious? Rob tim ___ kaffe mailing list [EMAIL PROTECTED] http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] State of the Verifier
Heyo, Can't you just use the signature like in code-analyse.c. Theres already a bunch of code in lookup.c for taking care of this stuff. Not really. The getField() and getClass() and getClassFromSignature() and stuff like that all cause the referenced class to be loaded and, in most cases, linked. The JanosVM versions don't, so you can try backporting those. I'll go ahead and give this a shot. If it works out, then we don't have to worry about all them reloading a previously failed class issues that you mentioned. Cheers, Rob ___ kaffe mailing list [EMAIL PROTECTED] http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
[kaffe] State of the Verifier
Hi all, Seeing as people would like to see 1.1.1 released, and as Jim is waiting for (among other things) me to submit the final verifier, I figured I'd give a quick update as to where I stand before I head out for the weekend to play frisbee on the beach :) In short, once I rewrite the class instance creation stuff to be compatible with the pass 3/pass 4 boundary, I'll post the verifier. Early next week. * Need to Rewrite Class Loading I've been frantically debugging the verifier in the last week against the regression tests and other programs. It turns out that I'm going to have to rewrite some of the class instance creation code in the core vm to allow type checking without class loading to occur. I'm still failing 5 regression tests that I shouldn't be. Once I fix the class loading situation, I know at least 3 of those will go away. * Subroutine Verification This was the big feature that has been missing the last year (and the major reason I didn't submit the verifier earlier). The specification is incredibly vague, so my verifier is not 100% compatible with either BCEL's (the most conservative) or Sun's (one of the most liberal). Either way, I've finished coding it up, after a number of false starts. * code-analyze.[ch] code-analyze does lots of checks that should have been performed in the verifier. Once the verifier is checked in, the next step is going to be to remove the checks from this file so that is simply puts together information for the JIT compilers. Cheers, Rob ___ kaffe mailing list [EMAIL PROTECTED] http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
