Status fields:
creation_ts: | 2005-07-22 01:02 |
---|---|
component: | jit |
version: | unspecified |
rep_platform: | i386 |
op_sys: | Linux |
bug_status: | CLOSED |
resolution: | INVALID |
reporter: | greenrd@greenrd.org |
This is probably just pure pedantry, but the JVM specification says (section 5.4.1): "A class or interface must be successfully verified before it is initialized." However, some verification failures - such as out-of-range targets of branches in a tableswitch - are reported by cacao only after class initialization is complete. Indeed, sometimes after some methods in the class have already been executed. I don't know if this matters "in the real world". I just noticed the discrepancy and I thought I'd point it out, just in case it turned out to be important.
This is one of the cases where the spec contradicts itself: [from Section 4.9.1 The Verification Process] Pass 4: For efficiency reasons, certain tests that could in principle be performed in Pass 3 are delayed until the first time the code for the method is actually invoked. In so doing, Pass 3 of the verifier avoids loading class files unless it has to. In fact it's not only for efficiency but correctness. There is a lot of code out there that assumes that only code which is actually executed is verified. (And only *when* it is executed for the first time.)
Well, to address the example of out-of-range targets: This actually *could* be performed right after loading without sacrifycing correctness. Since verification, however, cannot be completed anyway, I do not think it would make sense. This check is also delayed for "efficiency reasons", since we do not want to parse code that may never be executed.