Re: [Sablevm-user] JIT integration (was RE: bug report -- cannot run 'HelloWorld' test)

[Etienne M. G. <eg...@j-...>]

"Purtell, Andrew" wrote:
> You mentioned that another individual has approached you about
> integrating a JIT with SableVM. The only work required on the SableVM
> side for supporting any JIT is the integration of a generic interface
> that
> 
> 1) allows the JIT a means for substituting native code for bytecodes,
> e.g. a simple protocol for letting the interpreter know native code has
> been generated from bytecode and a means for insuring that subsequent
> method invocations transfer control to that native code

That's already in place in SableVM (that's how native methods are
called).

> 2) extends the runtime with a few native methods for accessing internal
> state normally not exposed, such as the constant pool

Hmmm... Currently, I do not keep a copy of the original bytecodes
around;  you might need that.  This is also related to the problem of
accessing the constant pool.

SableVM "prepares" the bytecode before execution;  It replaces Java
bytecodes by its own bytecodes and it resolves constant pool references,
and it sometimes stores the result along the transformed bytecodes (like
LDC).

Two choices:
1- SableVM keeps a copy of the original class file bytes around (on a
class and/or method basis?).
2- Some interface is defined that extracts "standard" information from
SableVM's instruction mapping.  The interface would ideally not be tied
to SableVM's internals (improving the portability of the JIT;-).

I would suggest (2-), but you will have to understand SableVM's internal
structure (not that hard).

> Note that having a JIT implemented mostly in Java means that the JIT,
> generated code, and associated state are first-class Java objects.
> 
> There would certainly be the expectation that this would be my work, and
> at various milestones patches would be submitted for consideration. If
> SourceForge CVS can be accessed by another protocol than pserver, then I
> could instead check in the work under a branch. Unfortunately our
> firewall blocks pserver, though rsh and ssh are allowed.

If you have "clean-room" status, I can certainly add you as an official
developer and give you write access to the ssh/cvs repository (see the
developers page for precise information).

Mainly, you shouldn't have signed the Sun community license, or had
access to any Sun "confidential" intellectual property (related to
Java;-).

> I expect that JIT compiled code can adhere to the requirements of the
> runtime environment, whatever they are. Whether or not there are
> performance losses because of them depends on how clever the JIT
> implementor is. :)

OK.

> 
> > What's the protocol for passing arguments and results back
> > and forth?  (does it also require ffi?)
> 
> Presumably a JIT would use the same convention and glue that is in place
> for invoking native methods. There is nothing that ties it to a
> particular library or convention, so those can change as need be. I
> develop on both the x86 and Alpha platforms. If this effort were to take
> off, I would eventually like to see a SableVM/JIT combination running on
> both.

You could initially restrict JIT-code->SableVM communication to JNI. 
(e.g., if native code needs to access a field, it has to use
GetFieldID/Get<type>Field).  The JIT generated code would still have an
advantage over pure JNI code, and that to make things efficient, 
GetFieldID could be called by the JIT and Get<type>Field encoded in the
JIT-generated code, thus saving potentially a big number of calls to
GetFieldID (if running in an inner loop).

SableVM->JIT-code will require a specialized interface, unless you plan
to put the generated code into a *.so library and ask SableVM to
dynamically link and resolve symbols, as it does for native (JNI)
calls.  But, ideally, it would mimic JNI in the idea that it would get a
JNIEnv pointer, an instance/class pointer.  The only different thing
would be that it would then receive a pointer to the remaining arguments
and it would return a pointer to the result.  (Unlike JNI methods that
declare all their parameters, and return values directly).  One
advantage you get over JNI is that this call can now be a simple
indirect call through a normal function pointer (JNI requires the
complex encoding of ffi to push/pop arguments/result appropriately on
the C native stack).

Side question: You don't plan to JIT every method, do you?  I think that
this could potentially make SableVM slower.  Have you investigated
"selective" JIT compilation?  I think this is one part where John might
have a few ideas;-)

Etienne
-- 
----------------------------------------------------------------------
Etienne M. Gagnon, M.Sc.                     e-mail: eg...@j-...
Author of SableVM:                             http://www.sablevm.org/
----------------------------------------------------------------------