sablevm-developer

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

[Andrew P. <apu...@ac...>]

> Etienne M. Gagnon <eg...@j-...> wrote:
> >   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?

I just wanted to make the source encoding explicit in the constant
class type.

> >       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.

Size means "number of 32 bit words". I guess its not really
necessary.
 
> >   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!

Hmm. I was thinking I might gain insight by looking at the internal
codes (although I haven't anything specific yet). However, I
suppose use of absolute addressing in the internal codes isn't
going to be the only problem down the road (and it is a problem 
now), so I'll stick to using the original Java bytecode. 

I haven't had much time this week to work on this. Hopefully next
week will be kinder...


Andy

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

[Andrew P. <apu...@ac...>]

> From: Etienne M. Gagnon <eg...@j-...>
> > John Leuner wrote:
> > 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
>
> Mainly:  just keep your mind open and try to push beyond what
> you see other have done!  But, I agree: it is important to know
> about what others have done;-)

I found a related paper ("An Empirical Study of Selective
Optimization"; Matthew Arnold, Michael Hind, and Barbara G.
Ryder; accessable from the link John provided) very interesting.
The result is the conclusion that coarse-grained profiling is
not only sufficient for determining which methods to aggresively
optimize, but is closer to optimal than all other considered
alternatives.

This is good... It means that we can select methods that will
likely benefit from JIT in a simple, low-overhead manner from
within the SableVM interpreter:

  1.  Interrupt normal processing every 10? 100? ms. 

      a.  Determine which method is currently executing.

      b.  If it is native, do nothing further.

      c.  Increment a counter which records how often this
          method was seen executing during profiling. If this
          counter exceeds a minimum value, continue; otherwise
          do nothing further.

      d.  Find (or create) an entry on the JIT's global "to
          do" list for this method (a simple doubly-linked 
          list).

      e.  Look at the previous list entry. If current->count 
          > prev->count; swap prev <-> current. (Only one swap,
          though, not bubblesort!)

      f.  Signal JIT if it is suspended.


  2.  In the JIT thread:

      a.  Remove top entry of "to do" list. If empty, suspend.

      b.  JIT compile.

      c.  goto a


Andy

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

[Andrew P. <apu...@ac...>]

> From: John Leuner <je...@pi...>
> I'm working on a separate little project to compile kissme into
> the linux kernel, this is of course completely non-portable, but
> provides excellent opportunity for using Java as a systems-level
> programming language, eg writing device drivers, managing memory
> etc.
> When combined with some clever run-time optimisation such as
> inlining, you could get a system that performs as fast as today's 
> monolithic kernel OSes (NT / Linux), but with all the benefits of
> the Java language.

Maybe NT. :)  Not Linux.

Seriously, I suppose you can really crunch during optimization and
end up with Java-derived native code that is nearly as fast as C-
derived native code, provided:

  - You never use virtual methods.

  - Either a) you never use exceptions; or b) your native code 
    never has to check an exception type before branching.

  - You never have to specify exact alignment or packing of a
    structure (neither of which can be guaranteed or even
    specified by the Java spec). Hmm... This can probably be
    restated as: You don't need 'C'-like structure accesses at
    all.

This, however, does not give you much of the benefits of the Java
language. It doesn't let you write network protocol stacks or
device drivers, either.


Andy