Re: [GCJ] Performance of GUI applications on embedded systems

Re: [GCJ] Performance of GUI applications on embedded systems

[ffileppo]

> Mark Wielaard wrote:
> > On Wed, 2008-11-05 at 09:24 +0100, ffileppo wrote:
> >> I tried your improvement but now I'm getting Segmentation Fault whenever I execute any GUI application.
> >> (Non-gui code is working fine)
> >>
> >> Do you have any idea to investigate this problem?
> >
> > Run it under GDB and post a backtrace please.
>
> For what it's worth, I very much suspect that this will be a build
> problem.  ffileppo, we also need to know what configure options you
> used.
>
> Andrew.
>


Hi,

I tried rebuilding gcj (with Andrew's improvement) on a clean system
but I'm still getting Segmentation Fault when I run GUI applications on my embedded system.

Here is configure :

Configured with: ../configure --prefix=/root/WiTP/inst-gcc --with-sysroot=/root/WiTP/f8/rootfs-f8 --disable-libssp --disable-libgomp --disable-libmudflap --enable-libgcj --disable-bootstrap --disable-multilib --disable-sjlj-exceptions --target=arm-linux-gnueabi --enable-languages=c,c++,java --with-build-time-tools=/root/WiTP/binutils-inst/arm-linux-gnueabi/bin --with-ld=/root/WiTP/binutils-inst/arm-linux-gnueabi/bin/ld --with-nm=/root/WiTP/binutils-inst/arm-linux-gnueabi/bin/nm --with-strip=/root/WiTP/binutils-inst/arm-linux-gnueabi/bin/strip --with-as=/root/WiTP/binutils-inst/arm-linux-gnueabi/bin/as --with-float=soft --enable-java-awt=gtk --x-libraries=/root/WiTP/arm-rpm/usr/lib


And here is GDB backtrace

#0  0x40b92d14 in java::lang::Object::getClass () from /lib/libgcj.so.10
#1  0x40b116f0 in javax::swing::JComponent::isPaintRoot () from /lib/libgcj.so.10
#2  0x42f9b114 in Java_gnu_java_awt_peer_gtk_FreetypeGlyphVector_getKerning (env=0x24320, obj=<value optimized out>, rightGlyph=40,
    leftGlyph=79, fnt=<value optimized out>, p=0x0)
    at ../../../../../../../libjava/classpath/native/jni/gtk-peer/gnu_java_awt_peer_gtk_FreetypeGlyphVector.c:204
#3  0x41381c30 in gnu::java::awt::peer::gtk::FreetypeGlyphVector::getKerning () from /lib/libgcj.so.10
#4  0x41383f4c in gnu::java::awt::peer::gtk::FreetypeGlyphVector::performDefaultLayout () from /lib/libgcj.so.10
#5  0x4137022c in gnu::java::awt::peer::gtk::FreetypeGlyphVector::FreetypeGlyphVector () from /lib/libgcj.so.10
#6  0x41368ac4 in gnu::java::awt::peer::gtk::GdkFontPeer::layoutGlyphVector () from /lib/libgcj.so.10
#7  0x40e977c0 in java::awt::Font::layoutGlyphVector () from /lib/libgcj.so.10
#8  0x40ef0d10 in java::awt::font::TextLayout::TextLayout () from /lib/libgcj.so.10
#9  0x41358b24 in gnu::java::awt::peer::gtk::GdkFontPeer$GdkFontMetrics::stringWidth () from /lib/libgcj.so.10
#10 0x41150c38 in javax::swing::JComponent::isPaintRoot () from /lib/libgcj.so.10
#11 0x41151704 in javax::swing::SwingUtilities::layoutCompoundLabel () from /lib/libgcj.so.10
#12 0x411c7ec0 in javax::swing::plaf::basic::BasicLabelUI::layoutCL () from /lib/libgcj.so.10
#13 0x411d2500 in javax::swing::plaf::basic::BasicLabelUI::getPreferredSize () from /lib/libgcj.so.10
#14 0x4111f6f0 in javax::swing::JComponent::getPreferredSize () from /lib/libgcj.so.10
#15 0x411bbfdc in javax::swing::plaf::basic::BasicListUI::updateLayoutState () from /lib/libgcj.so.10
#16 0x411944ec in javax::swing::plaf::basic::BasicListUI::maybeUpdateLayoutState () from /lib/libgcj.so.10
#17 0x4119c52c in javax::swing::plaf::basic::BasicListUI::installUI () from /lib/libgcj.so.10
#18 0x4111e778 in javax::swing::JComponent::setUI () from /lib/libgcj.so.10
#19 0x4111e8c0 in javax::swing::JList::setUI () from /lib/libgcj.so.10
#20 0x41143d48 in javax::swing::JList::updateUI () from /lib/libgcj.so.10
#21 0x4116f1bc in javax::swing::JList::init () from /lib/libgcj.so.10
#22 0x4116f230 in javax::swing::JList::JList () from /lib/libgcj.so.10
#23 0x00012d88 in MainPanel::MainPanel ()
#24 0x00012f80 in MainPanel::main ()
#25 0x40b7be60 in gnu::java::lang::MainThread::call_main () from /lib/libgcj.so.10
#26 0x40bfe85c in gnu::java::lang::MainThread::run () from /lib/libgcj.so.10
#27 0x40b99648 in _Jv_ThreadRun () from /lib/libgcj.so.10
#28 0x40b0d588 in _Jv_RunMain () from /lib/libgcj.so.10
#29 0x40b0d720 in _Jv_RunMain () from /lib/libgcj.so.10
#30 0x40b0d75c in JvRunMain () from /lib/libgcj.so.10
#31 0x424b5db8 in __libc_start_main () from /lib/libc.so.6
#32 0x0001255c in _start ()



I'll try to revert Andrew's patch to be sure that's the cause of segmentation fault.


Thank you,

Francesco

Re: [GCJ] Performance of GUI applications on embedded systems

[Andrew Haley]

ffileppo wrote:
>> Mark Wielaard wrote:
>>> On Wed, 2008-11-05 at 09:24 +0100, ffileppo wrote:
>>>> I tried your improvement but now I'm getting Segmentation Fault whenever I execute any GUI application.
>>>> (Non-gui code is working fine)
>>>>
>>>> Do you have any idea to investigate this problem?
>>> Run it under GDB and post a backtrace please.
>> For what it's worth, I very much suspect that this will be a build
>> problem.  ffileppo, we also need to know what configure options you
>> used.
>>
>> Andrew.
>>
>
>
> Hi,
>
> I tried rebuilding gcj (with Andrew's improvement) on a clean system
> but I'm still getting Segmentation Fault when I run GUI applications on my embedded system.
>
> Here is configure :
>
> Configured with: ../configure --prefix=/root/WiTP/inst-gcc --with-sysroot=/root/WiTP/f8/rootfs-f8 --disable-libssp --disable-libgomp --disable-libmudflap --enable-libgcj --disable-bootstrap --disable-multilib --disable-sjlj-exceptions --target=arm-linux-gnueabi --enable-languages=c,c++,java --with-build-time-tools=/root/WiTP/binutils-inst/arm-linux-gnueabi/bin --with-ld=/root/WiTP/binutils-inst/arm-linux-gnueabi/bin/ld --with-nm=/root/WiTP/binutils-inst/arm-linux-gnueabi/bin/nm --with-strip=/root/WiTP/binutils-inst/arm-linux-gnueabi/bin/strip --with-as=/root/WiTP/binutils-inst/arm-linux-gnueabi/bin/as --with-float=soft --enable-java-awt=gtk --x-libraries=/root/WiTP/arm-rpm/usr/lib

Unless you --enable-java-maintainer-mode the Java file won't be recompiled.

Andrew.

Re: [GCJ] Performance of GUI applications on embedded systems

[Andrew Haley]

Andrew Haley wrote:

> Unless you --enable-java-maintainer-mode the Java file won't be recompiled.

This change is now in gcj trunk.

Andrew.

Re: [GCJ] Performance of GUI applications on embedded systems

[ffileppo]

> >>>
> >> You're right.
> >> However I'm experiencing slowness when testing some other GUI sample application (e.g. the test case attached at the end).
> >>
> >> In this particular test case, the application takes a lot of time to startup (compared to the same device, running WinCE and CrEme JVM) and during start up the CPU usage is always at 100%.
> >>
> >> After startup, I'v also noticed that highlighting and/or clicking a certain number of times on buttons cause the application to hang and after that the CPU usage is always 100%.
> >
> > I've identified some serious GTK locking problems with this version of gcj.
> >
> > I'm investigating.
>
> Found a very silly (:-) merge error in CairoGraphics2D.c.
> This fixes it.
>
> I don't think there should be any differences between the GTK peers
> in Classpath and gcj, should there?  Or indeed, and differences between
> the CNI code in Classpath and gcj.
>
> Andrew.
>
>
> Index: gnu_java_awt_peer_gtk_CairoGraphics2D.c
> ===================================================================
> --- gnu_java_awt_peer_gtk_CairoGraphics2D.c	(revision 141575)
> +++ gnu_java_awt_peer_gtk_CairoGraphics2D.c	(working copy)
> @@ -351,7 +351,6 @@
>    for (i = 0; i < n; i++)
>      {
>        PangoFcFont *font = JLONG_TO_PTR(PangoFcFont, fonts[i]);
> -  gdk_threads_leave ();
>
>        /* Draw as many glyphs as possible with the current font */
>        int length = 0;
>
>

Hi Andrew,

I can see that with your patch the application now doesn't
hang anymore when highlighting and/or clicking on buttons.
GUI performance of applications on my embbeded
system seems also to be quite better now.

I wonder if there's still some place for UI performance
improvement.

Thank you,

Francesco

Re: [GCJ] Performance of GUI applications on embedded systems

[Andrew Haley]

ffileppo wrote:

> I can see that with your patch the application now doesn't
> hang anymore when highlighting and/or clicking on buttons.
> GUI performance of applications on my embbeded
> system seems also to be quite better now.

Good.

> I wonder if there's still some place for UI performance
> improvement.

I'm sure there is!  Patches welcome.

Andrew.

Re: [GCJ] Performance of GUI applications on embedded systems

[ffileppo]

> >> Here's one improvement.  If you can get rid of the places in the GTK peers
> >> where class and method lookups are performed at runtime you'll probably
> >> have a fix.  This shouldn't be a massive amount of work, just rather
> >> boring.
> >>
> >> In gcj,
> >>
> >>   * Compiled java code is quite fast.
> >>   * Class lookup by name is slow.
> >>   * Calling JNI code from compiled java code is quite fast.
> >>   * Calling compiled java code from JNI code is slow.
> >>   * Exceptions are slow.
>
> > I'm testing your patch on my embedded system and now I can see that GUI performance are very much better (particularly during application startup).
> >
> > Thank you so much!
> >
> > However running my test case (please see my first post) I see that CPU usage is always at 100% (after the application is running),
> > so the responsiveness is still not very good.
>
> What do you expect?  You're setting up a Timer with a delay of
> 0 milliseconds between events, and it's running continuously.
>
> Andrew.
>

You're right.
However I'm experiencing slowness when testing some other GUI sample application (e.g. the test case attached at the end).

In this particular test case, the application takes a lot of time to startup (compared to the same device, running WinCE and CrEme JVM) and during start up the CPU usage is always at 100%.

After startup, I'v also noticed that highlighting and/or clicking a certain number of times on buttons cause the application to hang and after that the CPU usage is always 100%.

I'm still trying to get oprofile working on my target device to see what's going wrong.

Thank you,
Francesco

Test case:

import javax.swing.JComponent;
import javax.swing.JFrame;
import java.awt.BorderLayout;
import javax.swing.JButton;
import javax.swing.JPanel;
import javax.swing.JTabbedPane;

public class GUITest {

  public static void main(String[] args) {

  JFrame frame = new JFrame();
  frame.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);
  JComponent newContentPane = new TestUI();
  frame.setTitle("TestUI");
  newContentPane.setOpaque(true);
  frame.setContentPane(newContentPane);
  frame.setBounds(10, 10, 500, 400);
  frame.setVisible(true);

  }

  static class TestUI extends JPanel {

  long startTime;
  JPanel createPanel(int start) {
  JPanel p = new JPanel();
  p.setLayout(null);

  for (int i=0; i<100; i++) {
      JButton ltit = new JButton("Variable "+(i+start)+": ");
      long val = System.currentTimeMillis() - startTime;
      JButton lval = new JButton(""+val);
      ltit.setBounds(5, 10+20*i, 150, 15);
      lval.setBounds(200, 10+20*i, 150, 15);
      p.add(ltit);
      p.add(lval);
  }
  return p;
  }

  TestUI() {
  super(new BorderLayout());
  startTime = System.currentTimeMillis();
  JTabbedPane p = new JTabbedPane();

  for (int i=0; i<10; i++) {
     JPanel page1 = createPanel(i*100+1);
     p.add("P"+i, page1);
  }

  add(p, BorderLayout.CENTER);
  }
  }

}

Re: [GCJ] Performance of GUI applications on embedded systems

[Andrew Haley]

ffileppo wrote:

> However I'm experiencing slowness when testing some other GUI sample application (e.g. the test case attached at the end).
> 
> In this particular test case, the application takes a lot of time to startup (compared to the same device, running WinCE and CrEme JVM) and during start up the CPU usage is always at 100%.
> 
> After startup, I'v also noticed that highlighting and/or clicking a certain number of times on buttons cause the application to hang and after that the CPU usage is always 100%.
> 
> I'm still trying to get oprofile working on my target device to see what's going wrong.

Well, it doesn't have to run on the target device.  It was easy for me
to duplicate your previous problem on my desktop machine with gcj and
oprofile.  There's nothing to stop you doing the same.

Andrew.


> Test case:
> 
> import javax.swing.JComponent;
> import javax.swing.JFrame;
> import java.awt.BorderLayout;
> import javax.swing.JButton;
> import javax.swing.JPanel;
> import javax.swing.JTabbedPane;
> 
> public class GUITest {
> 
>   public static void main(String[] args) {
> 
>   JFrame frame = new JFrame();
>   frame.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);
>   JComponent newContentPane = new TestUI();
>   frame.setTitle("TestUI");
>   newContentPane.setOpaque(true);
>   frame.setContentPane(newContentPane);
>   frame.setBounds(10, 10, 500, 400);
>   frame.setVisible(true);
> 
>   }
> 
>   static class TestUI extends JPanel {
> 
>   long startTime;
>   JPanel createPanel(int start) {
>   JPanel p = new JPanel();
>   p.setLayout(null);
> 
>   for (int i=0; i<100; i++) {
>       JButton ltit = new JButton("Variable "+(i+start)+": ");
>       long val = System.currentTimeMillis() - startTime;
>       JButton lval = new JButton(""+val);
>       ltit.setBounds(5, 10+20*i, 150, 15);
>       lval.setBounds(200, 10+20*i, 150, 15);
>       p.add(ltit);
>       p.add(lval);
>   }
>   return p;
>   }
> 
>   TestUI() {
>   super(new BorderLayout());
>   startTime = System.currentTimeMillis();
>   JTabbedPane p = new JTabbedPane();
> 
>   for (int i=0; i<10; i++) {
>      JPanel page1 = createPanel(i*100+1);
>      p.add("P"+i, page1);
>   }
> 
>   add(p, BorderLayout.CENTER);
>   }
>   }
> 
> }
> 

Re: [GCJ] Performance of GUI applications on embedded systems

[Andrew Haley]

ffileppo wrote:
>>>> Here's one improvement.  If you can get rid of the places in the GTK peers
>>>> where class and method lookups are performed at runtime you'll probably
>>>> have a fix.  This shouldn't be a massive amount of work, just rather
>>>> boring.
>>>>
>>>> In gcj,
>>>>
>>>>   * Compiled java code is quite fast.
>>>>   * Class lookup by name is slow.
>>>>   * Calling JNI code from compiled java code is quite fast.
>>>>   * Calling compiled java code from JNI code is slow.
>>>>   * Exceptions are slow.
>>> I'm testing your patch on my embedded system and now I can see that GUI performance are very much better (particularly during application startup).
>>>
>>> Thank you so much!
>>>
>>> However running my test case (please see my first post) I see that CPU usage is always at 100% (after the application is running),
>>> so the responsiveness is still not very good.
>> What do you expect?  You're setting up a Timer with a delay of
>> 0 milliseconds between events, and it's running continuously.
>>
>> Andrew.
>>
> 
> You're right.
> However I'm experiencing slowness when testing some other GUI sample application (e.g. the test case attached at the end).
> 
> In this particular test case, the application takes a lot of time to startup (compared to the same device, running WinCE and CrEme JVM) and during start up the CPU usage is always at 100%.
> 
> After startup, I'v also noticed that highlighting and/or clicking a certain number of times on buttons cause the application to hang and after that the CPU usage is always 100%.

I've identified some serious GTK locking problems with this version of gcj.

I'm investigating.

Andrew.

Re: [GCJ] Performance of GUI applications on embedded systems

[Andrew Haley]

Andrew Haley wrote:
> ffileppo wrote:
>>>>> Here's one improvement.  If you can get rid of the places in the GTK peers
>>>>> where class and method lookups are performed at runtime you'll probably
>>>>> have a fix.  This shouldn't be a massive amount of work, just rather
>>>>> boring.
>>>>>
>>>>> In gcj,
>>>>>
>>>>>   * Compiled java code is quite fast.
>>>>>   * Class lookup by name is slow.
>>>>>   * Calling JNI code from compiled java code is quite fast.
>>>>>   * Calling compiled java code from JNI code is slow.
>>>>>   * Exceptions are slow.
>>>> I'm testing your patch on my embedded system and now I can see that GUI performance are very much better (particularly during application startup).
>>>>
>>>> Thank you so much!
>>>>
>>>> However running my test case (please see my first post) I see that CPU usage is always at 100% (after the application is running),
>>>> so the responsiveness is still not very good.
>>> What do you expect?  You're setting up a Timer with a delay of
>>> 0 milliseconds between events, and it's running continuously.
>>>
>>> Andrew.
>>>
>> You're right.
>> However I'm experiencing slowness when testing some other GUI sample application (e.g. the test case attached at the end).
>>
>> In this particular test case, the application takes a lot of time to startup (compared to the same device, running WinCE and CrEme JVM) and during start up the CPU usage is always at 100%.
>>
>> After startup, I'v also noticed that highlighting and/or clicking a certain number of times on buttons cause the application to hang and after that the CPU usage is always 100%.
> 
> I've identified some serious GTK locking problems with this version of gcj.
> 
> I'm investigating.

Found a very silly (:-) merge error in CairoGraphics2D.c.
This fixes it.

I don't think there should be any differences between the GTK peers
in Classpath and gcj, should there?  Or indeed, and differences between
the CNI code in Classpath and gcj.

Andrew.


Index: gnu_java_awt_peer_gtk_CairoGraphics2D.c
===================================================================
--- gnu_java_awt_peer_gtk_CairoGraphics2D.c	(revision 141575)
+++ gnu_java_awt_peer_gtk_CairoGraphics2D.c	(working copy)
@@ -351,7 +351,6 @@
   for (i = 0; i < n; i++)
     {
       PangoFcFont *font = JLONG_TO_PTR(PangoFcFont, fonts[i]);
-  gdk_threads_leave ();

       /* Draw as many glyphs as possible with the current font */
       int length = 0;

Re: [GCJ] Performance of GUI applications on embedded systems

[Andrew Haley]

Andrew Haley wrote:

> 
> 
> Index: gnu_java_awt_peer_gtk_CairoGraphics2D.c
> ===================================================================
> --- gnu_java_awt_peer_gtk_CairoGraphics2D.c	(revision 141575)
> +++ gnu_java_awt_peer_gtk_CairoGraphics2D.c	(working copy)
> @@ -351,7 +351,6 @@
>    for (i = 0; i < n; i++)
>      {
>        PangoFcFont *font = JLONG_TO_PTR(PangoFcFont, fonts[i]);
> -  gdk_threads_leave ();
> 
>        /* Draw as many glyphs as possible with the current font */
>        int length = 0;

Incidentally, this bug was introduced on 2007-06-04, so this patch
needs applying to a bunch of systems and gcc branches.  It affects
Fedora systems and (presumably) recent Debians.

Andrew.

Re: [GCJ] Performance of GUI applications on embedded systems

[Andrew John Hughes]

2008/11/8 Andrew Haley <aph@redhat.com>:
> Andrew Haley wrote:
>
>>
>>
>> Index: gnu_java_awt_peer_gtk_CairoGraphics2D.c
>> ===================================================================
>> --- gnu_java_awt_peer_gtk_CairoGraphics2D.c   (revision 141575)
>> +++ gnu_java_awt_peer_gtk_CairoGraphics2D.c   (working copy)
>> @@ -351,7 +351,6 @@
>>    for (i = 0; i < n; i++)
>>      {
>>        PangoFcFont *font = JLONG_TO_PTR(PangoFcFont, fonts[i]);
>> -  gdk_threads_leave ();
>>
>>        /* Draw as many glyphs as possible with the current font */
>>        int length = 0;
>
> Incidentally, this bug was introduced on 2007-06-04, so this patch
> needs applying to a bunch of systems and gcc branches.  It affects
> Fedora systems and (presumably) recent Debians.
>
> Andrew.
>

So is the bug GCJ only? I got the impression we were also seeing this
on Classpath.
-- 
Andrew :-)

Support Free Java!
Contribute to GNU Classpath and the OpenJDK
http://www.gnu.org/software/classpath
http://openjdk.java.net

PGP Key: 94EFD9D8 (http://subkeys.pgp.net)
Fingerprint: F8EF F1EA 401E 2E60 15FA  7927 142C 2591 94EF D9D8

Re: [GCJ] Performance of GUI applications on embedded systems

[Mark Wielaard]

Hi Andrew,

On Sun, 2008-11-09 at 00:24 +0000, Andrew John Hughes wrote:
> So is the bug GCJ only? I got the impression we were also seeing this
> on Classpath.

I cannot replicate it with jamvm/classpath, so I assume it is gcj only.
The erroneous gdk_threads_leave () line is also not in the classpath CVS
sources.

Cheers,

Mark

Re: [GCJ] Performance of GUI applications on embedded systems

[Andrew Haley]

Andrew John Hughes wrote:
> 2008/11/8 Andrew Haley <aph@redhat.com>:
>> Andrew Haley wrote:
>>
>>>
>>> Index: gnu_java_awt_peer_gtk_CairoGraphics2D.c
>>> ===================================================================
>>> --- gnu_java_awt_peer_gtk_CairoGraphics2D.c   (revision 141575)
>>> +++ gnu_java_awt_peer_gtk_CairoGraphics2D.c   (working copy)
>>> @@ -351,7 +351,6 @@
>>>    for (i = 0; i < n; i++)
>>>      {
>>>        PangoFcFont *font = JLONG_TO_PTR(PangoFcFont, fonts[i]);
>>> -  gdk_threads_leave ();
>>>
>>>        /* Draw as many glyphs as possible with the current font */
>>>        int length = 0;
>> Incidentally, this bug was introduced on 2007-06-04, so this patch
>> needs applying to a bunch of systems and gcc branches.  It affects
>> Fedora systems and (presumably) recent Debians.
> 
> So is the bug GCJ only? I got the impression we were also seeing this
> on Classpath.

This one is gcj only, for sure.  This patch removes the difference
between gcj and Classpath.

Andrew.

Re: [GCJ] Performance of GUI applications on embedded systems

[ffileppo]

> Here's one improvement.  If you can get rid of the places in the GTK peers
> where class and method lookups are performed at runtime you'll probably
> have a fix.  This shouldn't be a massive amount of work, just rather
> boring.
>
> In gcj,
>
>   * Compiled java code is quite fast.
>   * Class lookup by name is slow.
>   * Calling JNI code from compiled java code is quite fast.
>   * Calling compiled java code from JNI code is slow.
>   * Exceptions are slow.
>
> Andrew.
>


Hi Andrew,

I'm testing your patch on my embedded system and now I can see that GUI performance are very much better (particularly during application startup).

Thank you so much!

However running my test case (please see my first post) I see that CPU usage is always at 100% (after the application is running),
so the responsiveness is still not very good.

Do you think that there is still some places for improvement?
I'll try to use oprofile on my embedded system to see what's going wrong

Best Regards,

Francesco

Re: [GCJ] Performance of GUI applications on embedded systems

[Andrew Haley]

ffileppo wrote:
>> Here's one improvement.  If you can get rid of the places in the GTK peers
>> where class and method lookups are performed at runtime you'll probably
>> have a fix.  This shouldn't be a massive amount of work, just rather
>> boring.
>>
>> In gcj,
>>
>>   * Compiled java code is quite fast.
>>   * Class lookup by name is slow.
>>   * Calling JNI code from compiled java code is quite fast.
>>   * Calling compiled java code from JNI code is slow.
>>   * Exceptions are slow.

> I'm testing your patch on my embedded system and now I can see that GUI performance are very much better (particularly during application startup).
> 
> Thank you so much!
> 
> However running my test case (please see my first post) I see that CPU usage is always at 100% (after the application is running),
> so the responsiveness is still not very good.

What do you expect?  You're setting up a Timer with a delay of
0 milliseconds between events, and it's running continuously.

Andrew.

Re: [GCJ] Performance of GUI applications on embedded systems

[Christian Thalinger]

On Thu, 2008-11-06 at 16:40 +0000, Andrew Haley wrote:
> What do you expect?  You're setting up a Timer with a delay of
> 0 milliseconds between events, and it's running continuously.

That may be because of this (taken from GNU Classpath's
vm/reference/java/lang/VMThread.java):

      // Note: JDK treats a zero length sleep is like Thread.yield(),
      // without checking the interrupted status of the thread.
      // It's unclear if this is a bug in the implementation or the spec.
      // See http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6213203

GCJ does this:

if (millis == 0 && nanos == 0)
    ++nanos;

and sleeps.  Maybe...

- Christian

Re: [GCJ] Performance of GUI applications on embedded systems

[ffileppo]

> Here's one improvement.  If you can get rid of the places in the GTK peers
> where class and method lookups are performed at runtime you'll probably
> have a fix.  This shouldn't be a massive amount of work, just rather
> boring.
>
> In gcj,
>
>   * Compiled java code is quite fast.
>   * Class lookup by name is slow.
>   * Calling JNI code from compiled java code is quite fast.
>   * Calling compiled java code from JNI code is slow.
>   * Exceptions are slow.
>
> Andrew.
>
>


Hi Andrew,

I tried your improvement but now I'm getting Segmentation Fault whenever I execute any GUI application.
(Non-gui code is working fine)

Do you have any idea to investigate this problem?

Thank you,

Francesco

Re: [GCJ] Performance of GUI applications on embedded systems

[Andrew Haley]

ffileppo wrote:
>> Here's one improvement.  If you can get rid of the places in the GTK peers
>> where class and method lookups are performed at runtime you'll probably
>> have a fix.  This shouldn't be a massive amount of work, just rather
>> boring.
>>
>> In gcj,
>>
>>   * Compiled java code is quite fast.
>>   * Class lookup by name is slow.
>>   * Calling JNI code from compiled java code is quite fast.
>>   * Calling compiled java code from JNI code is slow.
>>   * Exceptions are slow.

> I tried your improvement but now I'm getting Segmentation Fault whenever I execute any GUI application.
> (Non-gui code is working fine)
> 
> Do you have any idea to investigate this problem?

It didn't do that to me.

Where does the segfault occur?
Do you still get the segfault after backing out the patch?

Andrew.

Re: [GCJ] Performance of GUI applications on embedded systems

[Mark Wielaard]

On Wed, 2008-11-05 at 09:24 +0100, ffileppo wrote:
> I tried your improvement but now I'm getting Segmentation Fault whenever I execute any GUI application.
> (Non-gui code is working fine)
> 
> Do you have any idea to investigate this problem?

Run it under GDB and post a backtrace please.

Thanks,

Mark

Re: [GCJ] Performance of GUI applications on embedded systems

[Andrew Haley]

Mark Wielaard wrote:
> On Wed, 2008-11-05 at 09:24 +0100, ffileppo wrote:
>> I tried your improvement but now I'm getting Segmentation Fault whenever I execute any GUI application.
>> (Non-gui code is working fine)
>>
>> Do you have any idea to investigate this problem?
> 
> Run it under GDB and post a backtrace please.

For what it's worth, I very much suspect that this will be a build
problem.  ffileppo, we also need to know what configure options you
used.

Andrew.

Re: [GCJ] Performance of GUI applications on embedded systems

[ffileppo]

> > oprofile is your friend.  If you can get oprofile working on your
> > target system, please use it and find out if it does what you need.
>
> I did it.  The answer is appended.
>
> The problem is that the program is spending almost all of the time
> generating stack traces, millions and millions of them.
>
> Andrew.
>
>

Hi Andrew,
thanks a lot for your help.

Do you have any ideas to fix this problem?

Thank you,

Francesco

Re: [GCJ] Performance of GUI applications on embedded systems

[Andrew Haley]

ffileppo wrote:
>>> oprofile is your friend.  If you can get oprofile working on your
>>> target system, please use it and find out if it does what you need.
>> I did it.  The answer is appended.
>>
>> The problem is that the program is spending almost all of the time
>> generating stack traces, millions and millions of them.
>>

> Hi Andrew,
> thanks a lot for your help.
> 
> Do you have any ideas to fix this problem?

Here's one improvement.  If you can get rid of the places in the GTK peers
where class and method lookups are performed at runtime you'll probably
have a fix.  This shouldn't be a massive amount of work, just rather
boring.

In gcj,

  * Compiled java code is quite fast.
  * Class lookup by name is slow.
  * Calling JNI code from compiled java code is quite fast.
  * Calling compiled java code from JNI code is slow.
  * Exceptions are slow.

Andrew.


Index: classpath/include/gnu_java_awt_peer_gtk_FreetypeGlyphVector.h
===================================================================
--- classpath/include/gnu_java_awt_peer_gtk_FreetypeGlyphVector.h       (revision 141430)
+++ classpath/include/gnu_java_awt_peer_gtk_FreetypeGlyphVector.h       (working copy)
@@ -13,7 +13,7 @@
 JNIEXPORT void JNICALL Java_gnu_java_awt_peer_gtk_FreetypeGlyphVector_dispose (JNIEnv *env, jobject, jlongArray);
 JNIEXPORT jlong JNICALL Java_gnu_java_awt_peer_gtk_FreetypeGlyphVector_getNativeFontPointer (JNIEnv *env, jobject, jint);
 JNIEXPORT void JNICALL Java_gnu_java_awt_peer_gtk_FreetypeGlyphVector_getGlyphs (JNIEnv *env, jobject, jintArray, jintArray, jlongArray);
-JNIEXPORT jobject JNICALL Java_gnu_java_awt_peer_gtk_FreetypeGlyphVector_getKerning (JNIEnv *env, jobject, jint, jint, jlong);
+JNIEXPORT void JNICALL Java_gnu_java_awt_peer_gtk_FreetypeGlyphVector_getKerning (JNIEnv *env, jobject, jint, jint, jlong, jfloatArray);
 JNIEXPORT jdoubleArray JNICALL Java_gnu_java_awt_peer_gtk_FreetypeGlyphVector_getMetricsNative (JNIEnv *env, jobject, jint, jlong);
 JNIEXPORT jobject JNICALL Java_gnu_java_awt_peer_gtk_FreetypeGlyphVector_getGlyphOutlineNative (JNIEnv *env, jobject, jint, jlong);

Index: classpath/native/jni/gtk-peer/gnu_java_awt_peer_gtk_FreetypeGlyphVector.c
===================================================================
--- classpath/native/jni/gtk-peer/gnu_java_awt_peer_gtk_FreetypeGlyphVector.c  (revision 141430)
+++ classpath/native/jni/gtk-peer/gnu_java_awt_peer_gtk_FreetypeGlyphVector.c  (working copy)
@@ -169,9 +169,10 @@
   (*env)->ReleaseLongArrayElements (env, fonts, fontArray, 0);
 }

-JNIEXPORT jobject JNICALL
+JNIEXPORT void JNICALL
 Java_gnu_java_awt_peer_gtk_FreetypeGlyphVector_getKerning
-(JNIEnv *env, jobject obj __attribute__((unused)), jint rightGlyph, jint leftGlyph, jlong fnt)
+(JNIEnv *env, jobject obj __attribute__((unused)), jint rightGlyph, jint leftGlyph,
+ jlong fnt, jfloatArray p)
 {
   FT_Face ft_face;
   FT_Vector kern;
@@ -187,12 +188,10 @@

   pango_fc_font_unlock_face( font );

-  values[0].d = (jdouble)kern.x/64.0;
-  values[1].d = (jdouble)kern.y/64.0;
-
-  cls = (*env)->FindClass (env, "java/awt/geom/Point2D$Double");
-  method = (*env)->GetMethodID (env, cls, "<init>", "(DD)V");
-  return (*env)->NewObjectA(env, cls, method, values);
+  jfloat *pelements = (*env)->GetPrimitiveArrayCritical(env, p, NULL);
+  pelements[0] = (jfloat)kern.x/64.0;
+  pelements[1] = (jfloat)kern.y/64.0;
+  (*env)->ReleasePrimitiveArrayCritical (env, p, pelements, 0);
 }

 JNIEXPORT jdoubleArray JNICALL
Index: classpath/gnu/java/awt/peer/gtk/FreetypeGlyphVector.java
===================================================================
--- classpath/gnu/java/awt/peer/gtk/FreetypeGlyphVector.java    (revision 141430)
+++ classpath/gnu/java/awt/peer/gtk/FreetypeGlyphVector.java    (working copy)
@@ -247,7 +247,7 @@
   /**
    * Returns the kerning of a glyph pair
    */
-  private native Point2D getKerning(int leftGlyph, int rightGlyph, long font);
+  private native void getKerning(int leftGlyph, int rightGlyph, long font, float[] p);

   private native double[] getMetricsNative(int glyphCode, long font);

@@ -301,6 +301,7 @@
     GlyphMetrics gm = null;
     float x = 0;
     float y = 0;
+    float[] p = {0.0f, 0.0f};
     for(int i = 0; i < nGlyphs; i++)
       {
         gm = getGlyphMetrics( i );
@@ -314,9 +315,9 @@
         // using the same font
         if (i != nGlyphs-1 && fontSet[i] == fontSet[i+1])
           {
-            Point2D p = getKerning(glyphCodes[i], glyphCodes[i + 1], fontSet[i]);
-            x += p.getX();
-            y += p.getY();
+            getKerning(glyphCodes[i], glyphCodes[i + 1], fontSet[i], p);
+            x += p[0];
+            y += p[1];
           }
       }
     glyphPositions[nGlyphs * 2] = x;

Re: [GCJ] Performance of GUI applications on embedded systems

[Andrew Haley]

Andrew Haley wrote:
> ffileppo wrote:
>>>> oprofile is your friend.  If you can get oprofile working on your
>>>> target system, please use it and find out if it does what you need.
>>> I did it.  The answer is appended.
>>>
>>> The problem is that the program is spending almost all of the time
>>> generating stack traces, millions and millions of them.
>>>
> 
>> Hi Andrew,
>> thanks a lot for your help.
>>
>> Do you have any ideas to fix this problem?
> 
> Here's one improvement.  If you can get rid of the places in the GTK peers
> where class and method lookups are performed at runtime you'll probably
> have a fix.  This shouldn't be a massive amount of work, just rather
> boring.

Now,

163269   22.8358  libgcj.so.10.0.0         libgcj.so.10.0.0         _Jv_platform_gettimeofday()

calls to _Jv_platform_gettimeofday() are almost a quarter (!) of the
total runtime.

I think that's your fault.  Change your Timer.startTime to
something a little less aggressive.  :-)

Andrew.

[GCJ] Performance of GUI applications on embedded systems

[ffileppo]

Hi all,

I've been investigating about performance of java code compiled with gcj on embedded systems.
In particular I'm interested in testing AWT/SWING application using GTK/Xorg as graphical backend
(this is the only viable solution since QT peers are not well supported).

The embedded device I've been using for testing is a PXA270 processor (armv5te) equipped with 128Mb Ram;
running linux kernel 2.6.24 and using libgcj.so.10. GTK peers are running on Xorg, using matchbox
as window manager. The crosscompiler on my host is gcc 4.4.

During my tests I've noticed that java code using AWT/SWING (for example the test case attached at the end)
with GTK peer cause a very high load on the cpu.
Furthermore the applications take a lot of time to load and also the UI responsiveness is very slow.
Using "top" I can see that CPU is always at 100% during start up (it takes about 2 minutes
to get the application starting, Ram usage is ok).

I've also noticed that using optimizations (-O2, -O3...) does not help with graphical performance.

[On the same device, running WinCE and a commerical JVM (CrEme), applications have extremely better
graphical performance]

From my experience with this particual embedded system I can say that gcj has very high performance
when dealing with non-gui tasks (e.g. array sorting) compared with most of JVMs but gui
performance are very poor.

I would like to ask your opinion about the slowness of gui applications in my setup,
and also about viable solutions to improve this issue.
What do you think is the bottleneck?

-- libgcj itself?
-- GTK library / GTK peer implementation in classpath?
-- something dealing with Xorg?

Your feedback and ideas will be very appreciated.


Thank you,
Francesco


Test case:

import java.awt.BorderLayout;
import javax.swing.DefaultListModel;
import javax.swing.JComponent;
import javax.swing.JFrame;
import javax.swing.JLabel;
import javax.swing.JList;
import javax.swing.JPanel;
import javax.swing.JScrollPane;
import javax.swing.ListSelectionModel;
import javax.swing.SwingUtilities;
import javax.swing.event.ListSelectionEvent;
import javax.swing.event.ListSelectionListener;
import javax.swing.Timer;
import java.awt.event.*;


public class MainPanel extends JPanel implements ListSelectionListener {

  static final int NUM_ROWS = 500;

  JList list;
  JLabel lblSelection;
  DefaultListModel listModel;

  int startRow = 0;
  long startTime = 0;


javax.swing.Timer t = new javax.swing.Timer(0, new ActionListener() {
     public void actionPerformed(ActionEvent e) {
     long deltaTime = System.currentTimeMillis() - startTime;
     for (int i=startRow; i<NUM_ROWS; i++) {
     	listModel.set(i, ""+deltaTime);
     }

     startRow++;
     startTime = System.currentTimeMillis();

     }
});

public MainPanel() {
    super(new BorderLayout());

    listModel = new DefaultListModel();

    for (int i=0; i<NUM_ROWS; i++) {
    	listModel.addElement("Element "+i);
    }

    list = new JList(listModel);
    list.setSelectionMode(ListSelectionModel.SINGLE_SELECTION);
    list.setSelectedIndex(0);
    list.addListSelectionListener(this);
    list.setVisibleRowCount(5);

    JScrollPane listScrollPane = new JScrollPane(list);
    lblSelection = new JLabel(" ");
    add(lblSelection, BorderLayout.SOUTH);
    add(listScrollPane, BorderLayout.CENTER);
    t.start();
    startTime = System.currentTimeMillis();

}

public void valueChanged(ListSelectionEvent e) {
    if (e.getValueIsAdjusting() == false) {
      if (list.getSelectedIndex() == -1) {
        lblSelection.setText("");
      } else {
        lblSelection.setText("Item selected: "+list.getSelectedIndex());
      }
    }
}

public static void main(String[] args) {
    JFrame frame = new JFrame("TestUI #1");
    frame.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);
    JComponent newContentPane = new MainPanel();
    newContentPane.setOpaque(true); //content panes must be opaque
    frame.setContentPane(newContentPane);
    frame.setBounds(10, 10, 500, 400);
    frame.setVisible(true);
  }
}

Re: [GCJ] Performance of GUI applications on embedded systems

[Andrew Haley]

ffileppo wrote:

> I've been investigating about performance of java code compiled with gcj on embedded systems.
> In particular I'm interested in testing AWT/SWING application using GTK/Xorg as graphical backend
> (this is the only viable solution since QT peers are not well supported).
> 
> The embedded device I've been using for testing is a PXA270 processor (armv5te) equipped with 128Mb Ram;
> running linux kernel 2.6.24 and using libgcj.so.10. GTK peers are running on Xorg, using matchbox
> as window manager. The crosscompiler on my host is gcc 4.4.
> 
> During my tests I've noticed that java code using AWT/SWING (for example the test case attached at the end)
> with GTK peer cause a very high load on the cpu.
> Furthermore the applications take a lot of time to load and also the UI responsiveness is very slow.
> Using "top" I can see that CPU is always at 100% during start up (it takes about 2 minutes
> to get the application starting, Ram usage is ok).
> 
> I've also noticed that using optimizations (-O2, -O3...) does not help with graphical performance.
> 
> [On the same device, running WinCE and a commerical JVM (CrEme), applications have extremely better
> graphical performance]
> 
> From my experience with this particual embedded system I can say that gcj has very high performance
> when dealing with non-gui tasks (e.g. array sorting) compared with most of JVMs but gui
> performance are very poor.
> 
> I would like to ask your opinion about the slowness of gui applications in my setup,
> and also about viable solutions to improve this issue.
> What do you think is the bottleneck?
> 
> -- libgcj itself?
> -- GTK library / GTK peer implementation in classpath?
> -- something dealing with Xorg?

We can only speculate.

oprofile is your friend.  If you can get oprofile working on your
target system, please use it and find out if it does what you need.

Andrew.

Re: [GCJ] Performance of GUI applications on embedded systems

[Andrew Haley]

Andrew Haley wrote:
> ffileppo wrote:
> 
>> I've been investigating about performance of java code compiled with gcj on embedded systems.
>> In particular I'm interested in testing AWT/SWING application using GTK/Xorg as graphical backend
>> (this is the only viable solution since QT peers are not well supported).
>>
>> The embedded device I've been using for testing is a PXA270 processor (armv5te) equipped with 128Mb Ram;
>> running linux kernel 2.6.24 and using libgcj.so.10. GTK peers are running on Xorg, using matchbox
>> as window manager. The crosscompiler on my host is gcc 4.4.
>>
>> During my tests I've noticed that java code using AWT/SWING (for example the test case attached at the end)
>> with GTK peer cause a very high load on the cpu.
>> Furthermore the applications take a lot of time to load and also the UI responsiveness is very slow.
>> Using "top" I can see that CPU is always at 100% during start up (it takes about 2 minutes
>> to get the application starting, Ram usage is ok).
>>
>> I've also noticed that using optimizations (-O2, -O3...) does not help with graphical performance.
>>
>> [On the same device, running WinCE and a commerical JVM (CrEme), applications have extremely better
>> graphical performance]
>>
>> From my experience with this particual embedded system I can say that gcj has very high performance
>> when dealing with non-gui tasks (e.g. array sorting) compared with most of JVMs but gui
>> performance are very poor.
>>
>> I would like to ask your opinion about the slowness of gui applications in my setup,
>> and also about viable solutions to improve this issue.
>> What do you think is the bottleneck?
>>
>> -- libgcj itself?
>> -- GTK library / GTK peer implementation in classpath?
>> -- something dealing with Xorg?
> 
> We can only speculate.
> 
> oprofile is your friend.  If you can get oprofile working on your
> target system, please use it and find out if it does what you need.

I did it.  The answer is appended.

The problem is that the program is spending almost all of the time
generating stack traces, millions and millions of them.

Andrew.


259512   13.5589  libgcc_s.so.1            libgcc_s.so.1            execute_cfa_program
188702    9.8592  libgcc_s.so.1            libgcc_s.so.1            _Unwind_IteratePhdrCallback
169139    8.8371  libgcc_s.so.1            libgcc_s.so.1            uw_update_context_1
155408    8.1197  libgcj.so.10.0.0         libgcj.so.10.0.0         GC_mark_from
113082    5.9083  libgcc_s.so.1            libgcc_s.so.1            uw_frame_state_for
77219     4.0345  libgcj.so.10.0.0         libgcj.so.10.0.0         _Jv_platform_gettimeofday()
65323     3.4130  libc-2.8.so              libc-2.8.so              dl_iterate_phdr
61075     3.1910  no-vmlinux               no-vmlinux               (no symbols)
55123     2.8800  libgcc_s.so.1            libgcc_s.so.1            read_encoded_value_with_base
52303     2.7327  libpthread-2.8.so        libpthread-2.8.so        pthread_mutex_lock
42087     2.1989  libgcj.so.10.0.0         libgcj.so.10.0.0         GC_add_to_black_list_normal
38694     2.0217  libpthread-2.8.so        libpthread-2.8.so        __pthread_mutex_unlock_usercnt
32618     1.7042  libc-2.8.so              libc-2.8.so              strlen
27568     1.4404  libgcc_s.so.1            libgcc_s.so.1            _Unwind_Backtrace
27246     1.4235  libgcj.so.10.0.0         libgcj.so.10.0.0         GC_find_start
26285     1.3733  libgcj.so.10.0.0         libgcj.so.10.0.0         _Jv_FindCore(_Jv_core_chain*, java::lang::String*)
24849     1.2983  libgcc_s.so.1            libgcc_s.so.1            _Unwind_Find_FDE
21328     1.1143  libc-2.8.so              libc-2.8.so              memset
18771     0.9807  libz.so.1.2.3            libz.so.1.2.3            deflate_slow
18318     0.9571  libgcc_s.so.1            libgcc_s.so.1            get_cie_encoding
16052     0.8387  libgcj.so.10.0.0         libgcj.so.10.0.0         __gcj_personality_v0
14649     0.7654  libgcj.so.10.0.0         libgcj.so.10.0.0         _Jv_StackTrace::UnwindTraceFn(_Unwind_Context*, void*)
12847     0.6712  libgcj.so.10.0.0         libgcj.so.10.0.0         GC_find_header
11533     0.6026  libgcc_s.so.1            libgcc_s.so.1            base_from_cb_data
10373     0.5420  libgcj.so.10.0.0         libgcj.so.10.0.0         GC_local_gcj_malloc
9712      0.5074  libc-2.8.so              libc-2.8.so              memcpy
9000      0.4702  libgcj.so.10.0.0         libgcj.so.10.0.0         _Jv_IsAssignableFrom(java::lang::Class*, java::lang::Class*)
8478      0.4430  libgcc_s.so.1            libgcc_s.so.1            uw_update_context
8216      0.4293  libz.so.1.2.3            libz.so.1.2.3            fill_window
7534      0.3936  libfreetype.so.6.3.16    libfreetype.so.6.3.16    (no symbols)
7390      0.3861  libgcj.so.10.0.0         libgcj.so.10.0.0         _Jv_MonitorExit
6617      0.3457  libgcj.so.10.0.0         libgcj.so.10.0.0         _Jv_MonitorEnter
5593      0.2922  libgcj.so.10.0.0         libgcj.so.10.0.0         bool java::lang::String::equals(java::lang::Object*)
5521      0.2885  libgcj.so.10.0.0         libgcj.so.10.0.0         _Jv_NewPrimArray
5130      0.2680  libgcj.so.10.0.0         libgcj.so.10.0.0         _Jv_CheckArrayStore
4780      0.2497  libgcj.so.10.0.0         libgcj.so.10.0.0         GC_clear_stack_inner

Re: [GCJ] Performance of GUI applications on embedded systems

[Andrew Haley]

Andrew Haley wrote:
> Andrew Haley wrote:
>> ffileppo wrote:
>>
>>> I've been investigating about performance of java code compiled with gcj on embedded systems.
>>> In particular I'm interested in testing AWT/SWING application using GTK/Xorg as graphical backend
>>> (this is the only viable solution since QT peers are not well supported).
>>>
>>> The embedded device I've been using for testing is a PXA270 processor (armv5te) equipped with 128Mb Ram;
>>> running linux kernel 2.6.24 and using libgcj.so.10. GTK peers are running on Xorg, using matchbox
>>> as window manager. The crosscompiler on my host is gcc 4.4.
>>>
>>> During my tests I've noticed that java code using AWT/SWING (for example the test case attached at the end)
>>> with GTK peer cause a very high load on the cpu.
>>> Furthermore the applications take a lot of time to load and also the UI responsiveness is very slow.
>>> Using "top" I can see that CPU is always at 100% during start up (it takes about 2 minutes
>>> to get the application starting, Ram usage is ok).
>>>
>>> I've also noticed that using optimizations (-O2, -O3...) does not help with graphical performance.
>>>
>>> [On the same device, running WinCE and a commerical JVM (CrEme), applications have extremely better
>>> graphical performance]
>>>
>>> From my experience with this particual embedded system I can say that gcj has very high performance
>>> when dealing with non-gui tasks (e.g. array sorting) compared with most of JVMs but gui
>>> performance are very poor.
>>>
>>> I would like to ask your opinion about the slowness of gui applications in my setup,
>>> and also about viable solutions to improve this issue.
>>> What do you think is the bottleneck?
>>>
>>> -- libgcj itself?
>>> -- GTK library / GTK peer implementation in classpath?
>>> -- something dealing with Xorg?
>> We can only speculate.
>>
>> oprofile is your friend.  If you can get oprofile working on your
>> target system, please use it and find out if it does what you need.
> 
> I did it.  The answer is appended.
> 
> The problem is that the program is spending almost all of the time
> generating stack traces, millions and millions of them.

And one reason for that is pointless class lookups in
the GTK peer code.

Look at this:

Java_gnu_java_awt_peer_gtk_FreetypeGlyphVector_getKerning
(JNIEnv *env, jobject obj __attribute__((unused)), jint rightGlyph, jint leftGlyph, jlong fnt)
{
  ...

  cls = (*env)->FindClass (env, "java/awt/geom/Point2D$Double");
  method = (*env)->GetMethodID (env, cls, "<init>", "(DD)V");
  return (*env)->NewObjectA(env, cls, method, values);
}

Now, this method only returns a pair of points, and it would have been
trivial to pass a 2-element array into it, fill, with x and y, and
return the same array.  But no, we do a class lookup on
java/awt/geom/Point2D$Double and call its constructor with two
double values.

I don't know if this gross inefficiency in the GTK peer is the whole
cause of your pain, but it's a lot of it.

Andrew.

Re: [GCJ] Performance of GUI applications on embedded systems

[Roman Kennke]

Hi,

> > The problem is that the program is spending almost all of the time
> > generating stack traces, millions and millions of them.
> 
> And one reason for that is pointless class lookups in
> the GTK peer code.
> 
> Look at this:
> 
> Java_gnu_java_awt_peer_gtk_FreetypeGlyphVector_getKerning
> (JNIEnv *env, jobject obj __attribute__((unused)), jint rightGlyph, jint leftGlyph, jlong fnt)
> {
>   ...
> 
>   cls = (*env)->FindClass (env, "java/awt/geom/Point2D$Double");
>   method = (*env)->GetMethodID (env, cls, "<init>", "(DD)V");
>   return (*env)->NewObjectA(env, cls, method, values);
> }
> 
> Now, this method only returns a pair of points, and it would have been
> trivial to pass a 2-element array into it, fill, with x and y, and
> return the same array.  But no, we do a class lookup on
> java/awt/geom/Point2D$Double and call its constructor with two
> double values.

Or we could cache the MIDs and FIDs, like is recommended in all good JNI
books.

/Roman

-- 
Dipl.-Inform. (FH) Roman Kennke, Software Engineer, http://kennke.org
aicas Allerton Interworks Computer Automated Systems GmbH
Haid-und-Neu-Straße 18 * D-76131 Karlsruhe * Germany
http://www.aicas.com   * Tel: +49-721-663 968-48
USt-Id: DE216375633, Handelsregister HRB 109481, AG Karlsruhe
Geschäftsführer: Dr. James J. Hunt

Re: [GCJ] Performance of GUI applications on embedded systems

[Andrew Haley]

Roman Kennke wrote:

>>> The problem is that the program is spending almost all of the time
>>> generating stack traces, millions and millions of them.
>> And one reason for that is pointless class lookups in
>> the GTK peer code.
>>
>> Look at this:
>>
>> Java_gnu_java_awt_peer_gtk_FreetypeGlyphVector_getKerning
>> (JNIEnv *env, jobject obj __attribute__((unused)), jint rightGlyph, jint leftGlyph, jlong fnt)
>> {
>>   ...
>>
>>   cls = (*env)->FindClass (env, "java/awt/geom/Point2D$Double");
>>   method = (*env)->GetMethodID (env, cls, "<init>", "(DD)V");
>>   return (*env)->NewObjectA(env, cls, method, values);
>> }
>>
>> Now, this method only returns a pair of points, and it would have been
>> trivial to pass a 2-element array into it, fill, with x and y, and
>> return the same array.  But no, we do a class lookup on
>> java/awt/geom/Point2D$Double and call its constructor with two
>> double values.
> 
> Or we could cache the MIDs and FIDs, like is recommended in all good JNI
> books.

Sure, but it would be far slower.  Why would you want to call
constructors in the middle of a critical loop?

Andrew.

Re: [GCJ] Performance of GUI applications on embedded systems

[Andrew Haley]

Andrew Haley wrote:
> Andrew Haley wrote:
>> ffileppo wrote:
>>
>>> I've been investigating about performance of java code compiled with gcj on embedded systems.
>>> In particular I'm interested in testing AWT/SWING application using GTK/Xorg as graphical backend
>>> (this is the only viable solution since QT peers are not well supported).
>>>
>>> The embedded device I've been using for testing is a PXA270 processor (armv5te) equipped with 128Mb Ram;
>>> running linux kernel 2.6.24 and using libgcj.so.10. GTK peers are running on Xorg, using matchbox
>>> as window manager. The crosscompiler on my host is gcc 4.4.
>>>
>>> During my tests I've noticed that java code using AWT/SWING (for example the test case attached at the end)
>>> with GTK peer cause a very high load on the cpu.
>>> Furthermore the applications take a lot of time to load and also the UI responsiveness is very slow.
>>> Using "top" I can see that CPU is always at 100% during start up (it takes about 2 minutes
>>> to get the application starting, Ram usage is ok).
>>>
>>> I've also noticed that using optimizations (-O2, -O3...) does not help with graphical performance.
>>>
>>> [On the same device, running WinCE and a commerical JVM (CrEme), applications have extremely better
>>> graphical performance]
>>>
>>> From my experience with this particual embedded system I can say that gcj has very high performance
>>> when dealing with non-gui tasks (e.g. array sorting) compared with most of JVMs but gui
>>> performance are very poor.
>>>
>>> I would like to ask your opinion about the slowness of gui applications in my setup,
>>> and also about viable solutions to improve this issue.
>>> What do you think is the bottleneck?
>>>
>>> -- libgcj itself?
>>> -- GTK library / GTK peer implementation in classpath?
>>> -- something dealing with Xorg?
>> We can only speculate.
>>
>> oprofile is your friend.  If you can get oprofile working on your
>> target system, please use it and find out if it does what you need.
> 
> I did it.  The answer is appended.
> 
> The problem is that the program is spending almost all of the time
> generating stack traces, millions and millions of them.

And I've found the reason for that.  Every time anyone calls
gnu.java.awt.peer.gtk.GdkFontPeer$GdkFontMetrics.stringWidth, a
call is made to gnu.java.awt.peer.gtk.FreetypeGlyphVector.getKerning,
which does this:

  cls = (*env)->FindClass (env, "java/awt/geom/Point2D$Double");
  method = (*env)->GetMethodID (env, cls, "<init>", "(DD)V");
  return (*env)->NewObjectA(env, cls, method, values);

This call to FindClass does a dynamic lookup of java/awt/geom/Point2D$Double,
which requires that the class loaders are invoked in turn.  Each one
throws a ClassNotFoundException until the class is found.

Andrew.