[kaffe] bytecode verifier

[Dalibor Topic]

Hi Robert,

--- gonzo <Robert.N.Gonzalez at williams.edu> wrote:
> so i get to focus on the VM.  however, i need a VM
> with a full bytecode
> verifier as that (and the reflection libraries) are
> the two things that
> will need the most attention.

If I remeber it correctly from my last reflection bug
fixing round, our reflection implementation lacks a
full access control implementation, so we'd have to
fix that, too. It's a bit of a chain rection: proper
acces control requires Package support, which requires
java 1.2 style class loading which requires java 1.2
CodeSources which require a java 1.2 security
implementation. I've got semi working code for the
first and have started to approach the latter. But
I'll be fixing the Calendar & Co. bugs first, so it
might take some time before I can commit some new
reflection code.

> i spent a little time going through the code but,
> with only a first pass,
> i cannot determine what state code-analyse.* and
> verfify.* are in (other
> than missing stage 3 verification completely?). the
> website and the
> mailing archives indicate that it is incomplete. 
> does anyone know what's
> missing from them and, more importantly, how long it
> might take to
> complete it?

I'd like to cite from the cvs log for the pocketlinux
kaffe code-analyse2.c file:
* Major reworking of verifier:
	1. Removed code-analyse.c which didn't really do
anything useful

so a merge with that code might be interesting.

On the other hand, there is a patch that adds full
bytecode verification for kaffe 1.0.6:

http://www.kaffe.org/pipermail/kaffe/2001-August/007391.html

but it's not clear how well it works. You might want
to evaluate that one first, and tell us your results.
that one should have done the majority of missing
work, but had some issues, according to the mail
thread.

> i definitely agree with dalibor topic's suggestion
> that a plugin layer be
> added for the verifier.  if the builtin verifier is
> a long way off from
> being complete then it would be more worth my time
> to work on this plugin
> layer and link to justIce or the one in libgcj (btw
> - is there a license
> problem importing code into kaffe or linking to code
> from kaffe that
> is licensed under the gcc gnu+exception license?)
 
The plugin layer should be worth a good weekend of
hacking to get justIce up and running from within
java.lang.ClassLoader.

As you are most likely to call the verifier API from
ClassLoader.defineClass(byte [], int off, int len),
the natural choice for the verifier method is
verify(byte [] code, int off, int len). then you'd
have to write a VerifierManager, that essentially has
a single static method returning the current (system
property kaffe.verifier) verifier, and a class for
each verifier that manages argument passing. It should
be about a week of work altogether to get it into a
releasable form.

so there you go: one easy option - verifier API, and
one slightly harder: porting & finishing the full
bytecode verifier. Note that you might eventually
decide to port the full native verifier anyway because
there may be a nice performance benefit in using it,
at least on platforms without a JIT.

I'd recommend implementing the verifier API first, and
then evaluating your system's performance with kaffe's
verifier and justIce to see if it would be beneficial
to port the full verifier. After that, you might
consider a merge with the pocketlinux verifier to reap
eventual additional benefits in memory and speed.

As for merging code accross licensing boundaries:
avoid as long as you can ;) 

Regarding the libgcj verifier: ask gcj developers if
they have a verifier API, or if you could add one.
Once you have built kaffe's verifier API, you'd own
the copyright, and could contribute it to gcj on their
terms. Linking to GPL+Exception should not be a
problem, though. Incorporating GPL+Exception code
would require us to either keep the exception for that
code (which allows the originating project to merge
our eventual patches back into mainline) or to strip
it off (which the GPL allows, as far as I know, but
makes the information flow only in one direction). I'd
rather not have other project's pieces lying around
kaffe's source tree unmaintained ;)

best regards,

dalibor topic


__________________________________________________
Do You Yahoo!?
Yahoo! Autos - Get free new car price quotes
http://autos.yahoo.com