| Profiling Eclipse itself [message #104832] |
Fri, 13 July 2007 19:04  |
Eclipse User |
|
|
|
Has anybody using TPTP sucessfully performed a memory profile of an
Eclipse application?
I am trying to do a memory profile of my plugins. I ran into a number of
different problems with threads failing due to lack of memory and I seemed
to have solved them by upping the maximum memory to 1G for both my initial
Eclipse and my interior eclipse that was running my plugins.
After a very very long wait, it sort of brought up the interior eclipse
but then glibc detected an invalid pointer to munmap_chunk() and the
Eclipse application was ended. The following is small snippet of a
backtrace sent to the terminal:
*** glibc detected *** /home/jjohnstn/jdk1.5.0_08/jre/bin/java:
munmap_chunk(): invalid pointer: 0x60ec4280
====== Backtrace: ========
/lib/libc.so.6[0xb7eb0df1]
/lib/libc.so.6(cfree+0x90)[0xb7eb4430]
/home/jjohnstn/europa/eclipse/plugins/org.eclipse.tptp.platf rom.jvmti.runtime_4.4.0.v200706070100/agent_files/linux_ia32 /libJIE.so[0xb4dc2586]
....
I was also able to get a glibc double free exception from
org.eclilpse.equinox.launcher.gtk.linux.x86_1.0.0.v20070606/ eclipse_1017a.so
Are these known issues or any suggestions for getting this working?
I am using Fedora 7 on my x86 laptop. I just installed and updated
yesterday Per some suggestions here I downloaded TPTP rather than use the
update site.
-- Jeff
|
|
|
|
| Re: Profiling Eclipse itself [message #104859 is a reply to message #104845] |
Sat, 14 July 2007 19:30  |
| Eclipse User |
|
|
|
Originally posted by: jacek.pospychala.pl.ibm.com
Ed,
my experience is that, profiling goes fastest in standalone mode, when
profiling data is written to a log file. In other case, when Eclipse
client was collecting it, it looked like this client was eating most of
the cpu power and starving profiled process. To verify that I also tried
remote profiling, with profiled eclipse on one machine and client on
another, but without success - I got an NPE and no data on client side.
In remote profiling it would be even possible to manipulate whole
process, e.g. pause it, which is impossible in standalone.
To run standalone mode, you would need to install remote agent
controller, run it's bin\SetConfig.bat and launch ACServer.exe.
Then add something like this to eclipse command line (or eclipse.ini):
-agentlib:JPIBootLoader=JPIAgent:server=standalone,filters=. /filters.txt,file=trace.trcxml;CGProf
define following environment variables:
|TPTP_AC_HOME=<<Agent Controller Home>>|
|JAVA_PROFILER_HOME=%TPTP_AC_HOME%\plugins\org.eclipse.tptp. javaprofiler|
|PATH=%JAVA_PROFILER_HOME%;%PATH%;%TPTP_AC_HOME%\bin|
|PATH=%PATH%;%JAVA_HOME%\bin|
and finally launch eclipse.exe
trace.trcxml grows really fast. Additionally filters.txt (in eclipse
directory) may look like this:
org.eclipse.equinox* * EXCLUDE
org.eclipse.core.runtime* * EXCLUDE
org.eclipse.osgi* * EXCLUDE
org.eclipse.* * INCLUDE
* * EXCLUDE
Standalone mode is also described here:
http://help.eclipse.org/help33/index.jsp?topic=/org.eclipse. tptp.platform.doc.user/tasks/teprofsa.htm
Ed Merks wrote:
> Jeff,
>
> Yes, I tried this recently too on Windows and either got no data
> quickly, because the filters filtered out everything by default, or I
> crashed the (IBM) JVM and got no data that way more slowly. What I
> really wanted to be able to do was start up Eclipse without gather any
> data, warm up the application (to JIT all the code), and then start
> profiling to measure some particular action. But I couldn't get this
> to work. I wonder if there is a way to do this?
>
>
> Jeff Johnston wrote:
>> Has anybody using TPTP sucessfully performed a memory profile of an
>> Eclipse application?
>>
>> I am trying to do a memory profile of my plugins. I ran into a
>> number of different problems with threads failing due to lack of
>> memory and I seemed to have solved them by upping the maximum memory
>> to 1G for both my initial Eclipse and my interior eclipse that was
>> running my plugins.
>>
>> After a very very long wait, it sort of brought up the interior
>> eclipse but then glibc detected an invalid pointer to munmap_chunk()
>> and the Eclipse application was ended. The following is small
>> snippet of a backtrace sent to the terminal:
>>
>> *** glibc detected *** /home/jjohnstn/jdk1.5.0_08/jre/bin/java:
>> munmap_chunk(): invalid pointer: 0x60ec4280
>> ====== Backtrace: ========
>> /lib/libc.so.6[0xb7eb0df1]
>> /lib/libc.so.6(cfree+0x90)[0xb7eb4430]
>> /home/jjohnstn/europa/eclipse/plugins/org.eclipse.tptp.platf rom.jvmti.runtime_4.4.0.v200706070100/agent_files/linux_ia32 /libJIE.so[0xb4dc2586]
>>
>> ...
>>
>> I was also able to get a glibc double free exception from
>> org.eclilpse.equinox.launcher.gtk.linux.x86_1.0.0.v20070606/ eclipse_1017a.so
>>
>>
>> Are these known issues or any suggestions for getting this working?
>>
>> I am using Fedora 7 on my x86 laptop. I just installed and updated
>> yesterday Per some suggestions here I downloaded TPTP rather than
>> use the update site.
>>
>> -- Jeff
>>
|
|
|
| Re: Profiling Eclipse itself [message #105041 is a reply to message #104859] |
Sun, 15 July 2007 04:55 |
| Eclipse User |
|
|
|
Hi,
As stated, profiling in Standalone mode generates less overhead (both on
CPU and memory) and, combined with a decent filter, provides a better
and more scalable solution for profiling large applications such as
Eclipse itself.
Another possible usage model is to start the profiler in "enabled" mode
(-agentlib:JPIBootLoader=JPIAgent:server=enabled...). This loads the
profiler in "dormant" mode and allows you to attach to it later and
collect data. "enabled" mode in the new JVMTI Profiler is designed to
use dynamic bytecode instrumentation. That is, code is not instrumented
at all until the workbench is attached. However, due to some technical
issues, this was not fully implemented for 4.4. We are currently working
to enable this feature for the next release. The effort is tracked under
Bugzilla 179354
( https://bugs.eclipse.org/bugs/show_bug.cgi?sourceid=Mozilla- search&id=179354).
Thanks,
Asaf
--
Asaf Yaffe
Eclipse TPTP Committer, JVMTI Profiler
|
|
|
| Re: Profiling Eclipse itself [message #105053 is a reply to message #105041] |
Mon, 16 July 2007 11:19 |
| Eclipse User |
|
|
|
Hi.
To profile 'Eclipse Application' (aka Runtime Workbench), creating a good
filter is an important step. A filter that collects only your target
package/class/method but everything else should be created. For Example. I
create a filter to collect only jface class, but nothing else:
org.eclipse.jface* * INCLUDE
* * EXCLUDE
Similarly, you should create something like:
mypackage* * INCLUDE
* * EXCLUDE
The first line specifies that everything under your package is collected,
and the second line says everything else that does not fit previous filter
criteria will be excluded.
For the example I picked, it takes about 30-45sec for workbench to start
in a profile session. If there is nothing interested to be profiled at the
startup stage of workbench, you can pause monitoring the process before
workbench shows up. There is a 'pause' button at the toolbar of Profiling
monitor view (or via context menu of a selected process) that allows you
to pause monitoring. You will than resume profile by clicking on the
'Play' button (or context menu) to start profiling your runtime workbench
again. It takes less time for workbench to startup without collecting
profile data.
Hope this help.
|
|
|
Powered by
FUDForum. Page generated in 0.04255 seconds
Home