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
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
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
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
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
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
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
