This is the mail archive of the
java-patches@gcc.gnu.org
mailing list for the Java project.
Re: [patch] JNI performance improvements
- From: graydon hoare <graydon at redhat dot com>
- To: Bryce McKinlay <mckinlay at redhat dot com>
- Cc: java-patches at gcc dot gnu dot org
- Date: Fri, 14 Jan 2005 13:56:21 -0500
- Subject: Re: [patch] JNI performance improvements
- References: <41E6080C.9090608@redhat.com> <41E7F97A.60701@redhat.com>
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