Re: need to focus on java performance?

[David Daney <ddaney at avtrex dot com>]

Tom Tromey wrote:
> We do pay for our approach in 2 ways that I'm aware of.  One is that
> we compile everything PIC.  The other is that BC itself comes with a
> pretty big price -- 15% if I remember correctly.  That is a lot of
> overhead to have to overcome.
>   

I threw this idea out before, but since we are on the subject I will 
offer it up again (perhaps slightly revised):

The overhead (once a class is linked) in BC comes from all the 
indirection used by the current BC runtime linker.  I think it is 
possible to get rid of the indirection at the expense of a more complex 
(and less portable) linker.

<hand_waving>

My idea is to compile everything to use as little indirection as 
possible (similar to the current C++ ABI) except that all call targets 
initially point to linker stubs.  Similarly all data accesses initially 
point to a region of memory that will trap when accessed.

Whenever one of the stubs is traversed, or a there is trap in the 
special memory region, the runtime linker take over and patches the call 
site (perhaps after doing some linking and class initialization) so that 
the next time the call/memory access is direct to the properly 
initialized class.

Since it would be impossible to access an uninitialized class, all of 
those calls to Jv_initClass (or what ever it is called) could be eliminated.

The exact method of handling interface calls and access to non-static 
fields I have not fully thought out, but I think it should be possible 
to do them optimally.

</hand_waving>

* The ELF linker kind of works this way, but we would need a java 
specific runtime linker as it is unlikely that the glibc maintainers 
would want their ld.so hacked up.

* In addition to the linker, we would need several new relocation types 
to tag the parts of the code that would need to be patched up at 
runtime.  This might not be a problem, since we would have our own 
linker, we could make up what ever rules we wanted to.

*  All this runtime patching of the code would make it impossible to 
share code pages across different executables executing at the same 
time.  But JIT systems have this problem anyhow, so it would not be 
worse than that with respect to sharing code pages.  We could use a GOT 
so that all patching had good locality, but that requires more 
indirection which is the problem we are trying to solve.

* If we structured it with no GOT, there is no need to have PIC either, 
we could relocate everything when it is loaded/linked.  That would give 
slightly faster code.

* Not that I know that much about how JITs work, but this seems very 
similar to the things that a JIT would have to do, but simpler as we 
would just be patching up already generated code instead of doing the 
same thing with code that we were generating on the fly.

Well that is my initial brain dump.  Thinking about it really makes me 
want to get to work on it.  If I only had the time...

David Daney.