[patch] JNI performance improvements

[graydon hoare]

Bryce McKinlay wrote:

> will be common. For example, won't the AWT JNI code be re-entered 
> frequently now that we have a single event dispatch thread? ie: 
> gtk_main_iteration called from event thread via JNI, an event is 
> dispatched back to application which then makes another JNI call? 

a reasonable concern, but I think we're safe. the event dispatch thread 
basically switches back and forth (at a sufficiently high frequency -- 
I'm currently tuning this) between two phases of acticity:

phase 1:
   java event loop
     -> JNI
     -> gtk_main_iteration()
     -> gtk_event_callback_fooEvent()
     -> java.awt.EventQueue.enqueue(fooEvent)

phase 2:
   java event loop
     -> dispatch java fooEvent
     -> JComponent.paint()
     -> Graphics.drawLine()
     -> JNI
     -> gdk_draw_line()

both phases have only one JNI frame in them, most of the time (there are 
special cases like window reconfiguration which don't, but they're very 
rare). in any case, it's only phase 2 calls which really hurt us; the 
painting traffic is perhaps 100x as heavy as the event transferring.

in general I agree with your reasoning that more could be done here, in 
terms of keeping a cached frame chain. also, as tromey recommends, we 
could do a lot more to make local references faster. this was just low 
hanging fruit, but the profiles show it hits the cases which matter.

-graydon