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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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



[Index of Archives]     [Linux Kernel]     [Linux Cryptography]     [Fedora]     [Fedora Directory]     [Red Hat Development]

  Powered by Linux