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

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

Andrew Purtell wrote:
> 
> 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.

It's like you want... It would be easy to keep the raw code attribute
around, if necessary.

> How does this look?


>   public class org.sablevm.vm.Constant_UTF8
>   public class org.sablevm.vm.Constant_Unicode

I am unsure about these two...  Why not keep a single
"org.sablevm.vm.Constant_String", as the interpreter has presumably
already a native global reference to the string?  You can use
"java.lang.String" methods to get the length and characters.  Unless I
missed the point competely?...

>   public class org.sablevm.vm.Constant_Long
>       extends org.sablevm.vm.Constant
>   {
>       public long value;
>       public int size() { return 2; }
>   };


Why the "size"?  Don't you assume a long is 64 bits, as per
specification?  On a 64 bit processor, this would be a single word.  We
shouldn't make the JIT interface specific to an architecture.

>   public class org.sablevm.vm.Opcode  { ... };

As I said earlier, it would be possible to keep the original code array
around, to shield the JIT from SableVM specific internal codes,as much
as possible. SableVM encodes the destination of branches using absolute
addresses.  You certainly don't want to reverse engineer those
addresses!  

> I've only jotted down read-only methods so far. Eventually there will need
> to be an org.sablevm.vm.Class method for attaching prepared native code to
> a given method.
> 
> Note that these are NOT clases I plan to keep JIT state in during
> translation. There's an "org.sablevm.vm.jit.*" hierarchy I'm thinking over
> at the moment.
> 
> I was thinking the native methods implementing these classes could be added
> to libsablevm. 

Yes.

> The associated classes will need to be added to sablepath.

Yes.

> Seeing how both are pulled in only if they are part of the transitive
> closure of referenced classes/functions/etc., they cost nothing if the "use
> JIT" configure option is not enabled.

True.  (Exception of keeping the code array around, but we could
"#ifdef" this section of the class loader pretty easily).

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