harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rob Gonzalez <rob.gonza...@gmail.com>
Subject Re: class file reader
Date Tue, 17 May 2005 18:50:16 GMT
> > Is anyone familiar enough to suggest the interfaces for such a
> > module? :)
> 
> AFAICT, the verifier has the most simple possible interface: a static
> method called verify() which takes a bytearray representing a class. It
> throws ClassFormatError when the class does not pass verification.

Besides the bytes of the classfile itself, the verifier needs access
to the type hirearchy (e.g. to check that bytecode is statically type
safe) as well as the class loader associated with the given classfile
as verification of one class will typically cause others to be loaded
and linked as well.

Furthermore, according to the spec there are four steps to
verification, only the second of which takes a the full array of bytes
from a classfile and is the one that would typically throw a
ClassFormatError if a classfile is malformed.  I believe that this
pass more naturally fits as an element of the class loader and not of
the "verifier" module itself.

The third step, referred to as "bytecode verification" (e.g. the pass
that ensures static type correctness in the bytecode, that jumps don't
go into the middle of multi-byte instructions, that the JSR stuff is
alright, etc. etc.) is executed lazily during linking (not loading),
at which point the bytes of the classfile will probably not be in
memory as they started (e.g. they would have been replaced by some
object representation).  This step would throw VerifyErrors rather
than ClassFormatErrors.


So if we're talking about bytecode verification, then the interface
representing that module requires:
- a class representation, including the bytecode array for each method
(so something different than java.lang.Class)
- the class loader responsible for loading that class, which is used
to get other classes for type checking.

which is still a relatively simple interface, but a little more
involved than first hinted at.


> The tricky bits on this arer how to get it bootstrapped 8if written in
> java) so that it can verify system classes needed to initialize itself.
> I'm not sure of the gory details of the spec, but I guess a gcj-compiled
> version could take care of initial bootstrapping during VM
> initialization, until the verifier itself can be loaded and initialized,
> and then the java one would take charge. In this way one source module
> would do.
> 
> I'm not sure how this tricky issue is solved in the different VMs:
> - no verifier
> - naive verifier (just size, simple consistency checks) in C/C++
> - complete verifier
> - no verification of bootclasspath

No bytecode verification of the bootclasspath (though pass 2 still
happens, which does the basic consistency checks) is an option often
taken and I think a pretty good one.  Verification is provided for
classfiles that you don't trust, and if you're running a JVM you
probably should trust whatever standard library you've chosen (e.g.
classpath).

That said, if we're going for a truly pluggable interface it would be
worthwhile to explore the minimum number of classes that must
necessarily go into this set to avoid having two verifier
implementations; one at the bootstrap level and one for everything
else, so those classes would not be verified while everything else
might be (depending on what flags were sent to the VM upon execution;
e.g. -noverify).


cheers,
-Rob

Mime
View raw message