Re: need to focus on java performance?

[Bryce McKinlay <mckinlay at redhat dot com>]

Andrew Haley wrote:
> Bryce McKinlay writes:
>  > Andrew Haley wrote:
>  > > Once the class was initialized, you'd need to rewrite the
>  > > instructions in the trampolines to point to the static methods
>  > > that don't do class initialization.  While all this was going on,
>  > > there still would be threads jumping to these trampolines.
>  > > However, these trampolines are not themseolves protected by
>  > > locks, and there's no guarantee that you can rewrite the
>  > > instructions atomically.  So, you'd run the risk of a partially
>  > > rewritten instruction being executed.  If you can rewrite the
>  > > trampolines atomically then I think you might be OK.
>  > 
>  > Why rewrite the trampolines? Once a class is initialized, its
>  > atable entries are updated to point to the real function. Swapping
>  > function pointers in the atable is atomic.
>
> Ah, OK, you're fixing up the caller's pointers rather than anything in
> the target.  I can see that would work, but there are potentially many
> atable entries in many classes pointing to a static method.
Yeah, that's the (somewhat) tricky part - for each class we'd need to 
maintain links back to all the atables that reference it's static methods.

One alternative would be to give each class a static method table, and 
make static calls work using otable offsets into this - but of course, 
there could be a performance cost there.

>   Also, you'd need a fast way to find the caller.

Hmm, I don't think finding the caller is needed either, is it? We just 
need to create a unique trampoline for each (public) static method 
during class preparation. This would effect startup time, but assuming 
that most classes which are prepared eventually get initialized, memory 
overhead wouldn't be too bad.

Bryce