BTW, about optimization
gback at cs.utah.edu
Sun Jan 24 15:52:42 PST 1999
it's well-known how much Kaffe's jit sucks. Writing optimizing jit compilers
is not easy, however.
Instead of trying to do optimizations in the current code base, I would like
to propose a different approach. The approach I would like to see is to
separate the JIT from the rest of the VM. Clearly define an interface
to invoke the JIT, and parametrize the JIT with an interface to ask the
VM about the functions it needs. Ideally, the JIT component should be
integrated with or use the results of the as of now non-existent bytecode
verifier. Then, people with just an interest in optimizing the JIT can
replace the JIT component with an optimizing component --- just like
TYA plugs in Sun's JVM.
However, if there are optimizations that are cheap, we can of course
About your patches to do higher-order methods etc.; I can only speak
for myself, but I would not be willing to include those patches in full
in the main kaffe codebase. The reason is that kaffe is first and
foremost a virtual machine for Java as it is currently defined.
Of course, I can only speak for myself here.
However, I do realize that you (just like me) use kaffe to improve java
as it is defined, in one aspect or the other. While I believe that these
projects should not be part of Kaffe at this moment, I am very willing to
accommodate changes to kaffe which improve its modularity and ease your
integration effort in other ways.
Let's construct an example: if you had to define a third ENGINE, and added
I would be willing to accept a change that would eliminate this #ifdef
and be simply:
where you use configure magic to provide different implementations for
kiev, the intr, and the translator.
I know that example is not correct, because you don't (or at least the
last time you said you couldn't) use a third engine; but hopefully, you
get the jist here.
More information about the kaffe