Re: [Sablevm-developer] reflection classes for constant pool and bytecode data

[John L. <je...@pi...>]

Hi Guys

> Anybody else has comments?  (I think we should CC John Leuner, which I
> am doing now).  Maybe he'll be interested to being added as a developer,
> too? (This last question is directed to John;-)

Yes please. (I'm on the sablvm-developer list already).

> > Hi, SableVM developers!
> > 
> > I've been looking over the SableVM sources and I think the first step
> > toward creating a JIT should be the addition of a simple class hierarchy
> > containing native methods for exposing SableVM's internal representations
> > of the constant pool and (prepared) bytecodes to the Java environment.
> > I've been working this week with some classes I've cobbled together for
> > parsing class files directly from disk, but keeping the class data in
> > memory solely for a JIT's use is wasteful.

I was wondering if this interface needs to be sablevm specific? All JVMs
will be able to provide the information you're asking for here, and
probably in exactly the same format. I'm thinking here of cloning this
work with my JVM, ultimately I would like to have whatever JIT framework
we develop here running on both JVMs. 

Of course there are things that might differ, eg the 
> >       public org.sablevm.vm.Class clazz;     // class containing this method
> >       public int access_flags;

access flags. But if you're only looking for the standard ACC_PUBLIC,
ACC_PROTECTED etc, it should be ok.

> >       public int max_stack;
> >       public int max_locals;
> >       public int exception_table[][];

How does this store the exception type?

> >       public org.sablevm.vm.Opcode code[];   // method opcodes
> >       ...
> >   }


As regards my own work on my primitive bytecode-to-assembly translator,
I've managed to encode exception handlers within the native(optimised) 
code now.
Thus:

try {
	int[] array = null;
	array[3] = 2;
} catch(NullPointerException npe)
 {
	return 2;
 }

will return 2 from the native (optimisedd) method without invoking a very
expensive search of the stack frames for execption handlers. 

Also, if native code generates an exception (these usually come from
bytecodes that use object / array references, or method invocations) it
will pass it upwards for the calling method to deal with. 

My next problem to solve is to make sure that I match the type of the
exception correctly. The problem is that the exception must be
type-checked at runtime, so I have to generate the equivalent of:

exception object in eax

if( DEREF(eax)->pstType == type in exception handler)
  jump to handler
carry on

So for me this means parsing the C structure that represents the tObject
structure, and finding at what offset the pstType member is. 

This has led me to write a C preprocessor which strips comments, and one
which processes the #define #ifdef, #endif statements so that I can start
manipulating the C structure within the runtime optimiser. All of this is
in Java, I'm using the ANTLR compiler-compiler to generate lexers and
parsers. ( I noticed SableCC just now, will look at that).

Once I complete this I hope my optimiser will be pretty much finished ... 
I suppose I still have to monitors and there are issues with invokespecial
and others, but these are just a matter of rewriting the code.




I want to point you guys to some papers ( I read some of these last
weekend and they gave me lots of food for thought):

http://www-4.ibm.com/software/developer/library/jalapeno/index.html

Is an excellent overview of Jalapeno, it discusses locking (which I want
to reimplement on my JVM), has a good high-level description of the whole
Optimiser. 

An article on the optimiser itself:

"THe Jalapeno Dynamic optimizing compiler for Java" -
http://www.research.ibm.com/jalapeno/publication.html#grande99

And on runtime selection of methods to optimise:

"An empirical study of Selective optimisation" -
http://www.research.ibm.com/jalapeno/publication.html#lcpc00




John Leuner