Re: need to focus on java performance?

[Andrew Haley <aph at redhat dot com>]

Bryce McKinlay writes:
 > 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.

Eww, yuck.  OK, now I see where you're coming from.

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

Right.

 > >   Also, you'd need a fast way to find the caller.
 > 
 > Hmm, I don't think finding the caller is needed either, is it?

You said so above: you need to get from the callee to the caller(s).
You suggested doing this by maintaining links.  :-)

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

Perhaps not, no.  I'm just a bit concerned that we're adding to
startup time.  I know that my recent patches haven't exactly helped
startup time either.  ;-)

Andrew.