[kaffe] JIT optimization questions

[Dalibor Topic]

--- gonzo <Robert.N.Gonzalez at williams.edu> wrote:
> in bytecode.h constants CHECKCAST_FAST and
> INSTANCEOF_FAST are declared,
> and their only usage in the source code seems to be
> in code-analyse.c,
> where their use is commented out!

They seem to have been instructions in an early
implementation of kaffe.def but don't seem to be used
any longer.

http://www.mit.edu/afs/sipb/project/jolt/src/kaffe-0.9.2/kaffe/kaffevm/kaffe.def

it should be safe to remove them. Send me a patch.

> first, what, if any, code analysis is currently done
> for the JIT before
> it's run (and where is that analysis done).

Grepping around and looking at the source I think that
it all happens this way:

jit3 calls verifyMethod in code-analyse.c which among
other things creates a codeinfo structure. jit3 uses
codeinfo to for register slot allocation (grep for
codeInfo in jit3/machine.c for details).

Now, according to the comment in verify.c:

        /* Run bytecode verifier - for reasons only
known to the Sun gods
         * you are suppose to verify the bytecodes for
each method at link
         * time rather than when you run the damn
thing.  It's much more
         * useful to run the verifier on demand
because it creates lots of
         * info which helps the JIT code generator.  I
suppose to conform
         * to the spec we'll just have to run it twice
- once here for
         * compatibility reasons, and once on demand
to get the JIT info.
         * Hey ho ...
         */


we are running the verifier a second time for the jit
just to get the codeInfo. It might make sense to
separate codeInfo generation from verification. I
don't know if it is feasible, though. What does the
full verification patch do about it?

On the other hand, the only invocations of
verifyMethod I see are in $engine/machine.c. intrp
does nothing with it, except to call tidyVerifyMethod.
jit one apparently uses it to generateInsnSequence,
and in a couple of other places. jit3 does what I said
above.

> second, is there a good reference (or two) out there
> on JIT optimizations
> and code analysis techniques used for them that
> someone could point me to.

there are some papers on how the jit is integrated in
kaffe here:
http://www.cs.pdx.edu/~sanseri/kaffe/

If you are looking for general JIt optimization
references, try the citeseer search engine.

> third, if we plan on using the code analysis done at
> the verifier stage
> for JIT optimization (as opposed to doing analysis
> for verification and
> optimization in two separate steps), then it would
> make the verifier
> plugin API that i was thinking of putting in useless
> and require us to go
> with our own in-house verifier that adds the
> information required by the
> JIT compiler.  what are the thoughts of everyone on
> this?  i personally
> like the API idea (ie - do the verification and
> analysis for optimization 
> completely separately) as it makes finding holes in
> the verifier much
> easier for us.  though if we do decide to do all the
> analysis at the
> same time, the authors of the verifier patch (which
> is almost 1.0.7 ready)
> claim that their verifier is complete but too strict
> in the case of
> implementing multiple interfaces (ie - it won't
> accept some code that it
> should, but other than that it's fine) so we could
> use that as a
> preliminary verifier in which to put our
> optimization analysis.

I'd like to see a verifier API, for all the good
reasons you point out. But it might be better to first
integrate the full verifier patch, fix it for the
multiple interface case, and then separate code along
the issues. Otherwise it could be quite hard to patch
things together again.


best regards,

dalibor topic

__________________________________________________
Do You Yahoo!?
Yahoo! Health - Feel better, live better
http://health.yahoo.com