Re: AMPC 1.4.3 released (C to Java Class Files compiler suite)

The problem comes in the form of terrible efficiency. As I understand
it, array indexing in the JVM wouldn't be able to take advantage of the
fact that you're accessing a sequential range of bytes. Something like
this is very efficient in native code, but would slow down by maybe
10-100 times if you have to use array indexing and you have to re-index
into the array each time thru the loop.


This C code is very efficient:


        while(*p++)
                do_something(p);


Maybe a Java translation might be something like this:


      for (int i=0; i < p.length(); i++)
              do_something(p[i]);


These look similar, but the C-produced native code can use an index
register to scan memory efficiently. The Java-produced byte code would
likely re-index into the array for each iteration through the loop.
Array indexing is pretty slow because you don't get the advantage of
knowing that you're accessing a sequential range of bytes. Maybe a JIT
compiler could do something to make this more efficient, but it seems
like this would perform poorly in an interpreted JVM.


However, if the JVM understood the concept of dereferencing a pointer
to a memory location this could be much faster. This is done in the
.NET CLR and they were able to do it while still keeping type safety
and verifiable code. It's actually simple to define this type of
operation, but it looks to me that Sun went out of their way to avoid
doing this. Their fear of pointers was taken to an extreme, even though
it could have been done in a safe manner.


Eric

Return to the comp.compilers page.
Search the comp.compilers archives again.