Eclipse Community Forums: Test and Performance Tools Platform (TPTP)

Home » Archived » Test and Performance Tools Platform (TPTP) » Porting issue. The Second step.

Porting issue. The Second step. [message #126587]

Mon, 17 March 2008 10:52

Eclipse User

Originally posted by: ck2329.mail.ru

I'm happy to say that now Eclipse is able to show some info from my
target(linux mips) -heap and gc profilers are partitially in working state.

But anyway tptp is still extremely unstable.

Issue list:
1) It is impossible to connect threadProf - it fails on registering
MonitorWait event, MonitorWaited event etc capabilities on the JVM.

2) It is impossible to "attach to agent" from the first attempt - first i
should attach(i checked fileter - it is empy and named as "Default") -
then Detach from Agent - then attach again(now filter will be not empty
and named as "__JVMPI__" )

3) After first succesfull connecting to jvmti agent(server=enabled;
HeapProf) through AC and then stopping profiling session - it is
impossible to connect one more time.

4) If i choose "Run GC" then jvmti agent causes Segmentation fault

5) If i choose terminate process - then agent receives Kill signal - but
AC is already dead because of segmentation fault.

Please give some comments to the mentioned above if possible.

Re: Porting issue. The Second step. [message #126842 is a reply to message #126587]

Wed, 19 March 2008 03:20

Eclipse User

Originally posted by: ck2329.mail.ru

Any suggestions ? sorry for up.

Re: Porting issue. The Second step. [message #126866 is a reply to message #126587]

Wed, 19 March 2008 04:27

Eclipse User

Andrew,

> I'm happy to say that now Eclipse is able to show some info from my
> target(linux mips) -heap and gc profilers are partitially in working state.
>
> But anyway tptp is still extremely unstable.
>
> Issue list:
> 1) It is impossible to connect threadProf - it fails on registering
> MonitorWait event, MonitorWaited event etc capabilities on the JVM.

Can you provide more information? Does it fail when invoking JVMTI
SetEventNotificationMode? If so, what is the returned error code? If
not, where does it fail?

What JVM are you targeting (use 'java -version' on the target MIPS machine)?

>
> 2) It is impossible to "attach to agent" from the first attempt - first
> i should attach(i checked fileter - it is empy and named as "Default") -
> then Detach from Agent - then attach again(now filter will be not empty
> and named as "__JVMPI__" )

Can you provide more information? What do you mean by "first attempt"?
Where does it fail? Is this an Agent Controller issue? Agent issue?
Martini issue?

>
> 3) After first succesfull connecting to jvmti agent(server=enabled;
> HeapProf) through AC and then stopping profiling session - it is
> impossible to connect one more time.

Again, more information will be helpful (see previous question).

>
> 4) If i choose "Run GC" then jvmti agent causes Segmentation fault

Can you provide a stack dump (preferably in debug mode)? If not, can you
point to the module causing the crash?

>
> 5) If i choose terminate process - then agent receives Kill signal - but
> AC is already dead because of segmentation fault.

Again... stack dump...

>
> Please give some comments to the mentioned above if possible.
>

We'll do our best :)

Thanks,

--
Asaf Yaffe
Eclipse TPTP Committer, JVMTI Profiler

Re: Porting issue. The Second step. [message #126878 is a reply to message #126866]

Wed, 19 March 2008 05:42

Eclipse User

Originally posted by: ck2329.mail.ru

Asaf Yaffe wrote:

>> Issue list:
>> 1) It is impossible to connect threadProf - it fails on registering
>> MonitorWait event, MonitorWaited event etc capabilities on the JVM.

> Can you provide more information? Does it fail when invoking JVMTI
> SetEventNotificationMode? If so, what is the returned error code? If
> not, where does it fail?
> What JVM are you targeting (use 'java -version' on the target MIPS machine)?

It fails in CJVMTIInterface::RegisterEvent when calls to
m_pJVMTIInterface->AddCapabilities. return code is 98 - which means -
not_available. now im using latest cvm (rev62). Now im trying to
understand if cvm really doesnt support this event or something is wrong
with my request from martini side.

>>
>> 2) It is impossible to "attach to agent" from the first attempt - first
>> i should attach(i checked fileter - it is empy and named as "Default") -
>> then Detach from Agent - then attach again(now filter will be not empty
>> and named as "__JVMPI__" )

> Can you provide more information? What do you mean by "first attempt"?
> Where does it fail? Is this an Agent Controller issue? Agent issue?
> Martini issue?

As i said to get some results in Eclipse i should attach to agent[FIRST
ATTEMPT] - then Detach from Agent - then attach again[SECOND ATTEMPT].
Actully there is no failure on first attempt - i just cannot get any info
in eclipse. I tried both with server = enabled and controlled

>>
>> 3) After first succesfull connecting to jvmti agent(server=enabled;
>> HeapProf) through AC and then stopping profiling session - it is
>> impossible to connect one more time.

> Again, more information will be helpful (see previous question).

Current situation is a little bit different - i can connect - but
application seems to be frozen . according to your previous explanation i
applied patch https://bugs.eclipse.org/bugs/show_bug.cgi?id=186080 but it
works only for the first attach.

>>
>> 4) If i choose "Run GC" then jvmti agent causes Segmentation fault

> Can you provide a stack dump (preferably in debug mode)? If not, can you
> point to the module causing the crash?

>>
>> 5) If i choose terminate process - then agent receives Kill signal - but
>> AC is already dead because of segmentation fault.

> Again... stack dump...

Now on going

>>
>> Please give some comments to the mentioned above if possible.
>>

> We'll do our best :)

I see! Thanks for your suport, i'll try to help you - if i know the answer
for other user's quetion - i'll reply!

One more question - how can i get latest (4.5) sources - is it HEAD
revision on main repository or you have dedicated one ?

> Thanks,

Re: Porting issue. The Second step. [message #126904 is a reply to message #126878]

Wed, 19 March 2008 07:23

Eclipse User

Andrew V. Novoselsky wrote:

> It fails in CJVMTIInterface::RegisterEvent when calls to
> m_pJVMTIInterface->AddCapabilities. return code is 98 - which means -
> not_available. now im using latest cvm (rev62). Now im trying to
> understand if cvm really doesnt support this event or something is wrong
> with my request from martini side.

The various monitor events require the JVM to possess the
"can_generate_monitor_events" JVMTI capability. This is the bare
minimum. To do something useful with the event, more capabilities are
usually required. The Martini implementation for these events requires
the JVM to possess the following capabilities (see
JVMTIInterface.cpp::CJVMTIInterface::InitEventTranslationArr ays):
can_generate_monitor_events, can_get_monitor_info, can_tag_objects,
can_get_current_contended_monitor). It seems that at least one of these
are not supported by your target JVM. Please try to determine which, so
I can better assess the implications.

Thanks,
Asaf

--
Asaf Yaffe
Eclipse TPTP Committer, JVMTI Profiler

Re: Porting issue. The Second step. [message #126918 is a reply to message #126904]

Wed, 19 March 2008 09:45

Eclipse User

Originally posted by: ck2329.mail.ru

Thanks . You are right prroblem was caused by can_get_monitor_info. I
turned it on on my JVM - no ThreadProfiler works.

I chacked threadProf on my sample app. And results are confusing. My app
is running very very slow with tptp profiler.I tried to run NetBeans
profiler on the same target - it is more then 10 times faster :-(.
Probably i can make tptp faster by specifiyng some kind of filter? Now i
use just default settings. Can i ?

Re: Porting issue. The Second step. [message #126931 is a reply to message #126918]

Wed, 19 March 2008 10:01

Eclipse User

Andrew V. Novoselsky wrote:
> Thanks . You are right prroblem was caused by can_get_monitor_info. I
> turned it on on my JVM - no ThreadProfiler works.
>
> I chacked threadProf on my sample app. And results are confusing. My app
> is running very very slow with tptp profiler.I tried to run NetBeans
> profiler on the same target - it is more then 10 times faster :-(.
> Probably i can make tptp faster by specifiyng some kind of filter? Now i
> use just default settings. Can i ?

Do you experience this slowdown with ThreadProf or with another profiler
(CGProf, HeapProf)?

ThreadProf does not support filtering at the moment.

Filtering is supported in CGProf and HeapProf. Please check the online
documentation for instructions on how to specify filters.

The main reason for the poor performance of the TPTP Profilers (compared
to other profilers such as NetBeans) is the use of an inefficient XML
data stream. The "core" profiling runtime (i.e., Martini) is quite
efficient and does not create a lot of overhead.

BTW - TPTP 4.5 work is in the HEAD revision.

Regards,
Asaf

--
Asaf Yaffe
Eclipse TPTP Committer, JVMTI Profiler

Re: Porting issue. The Second step. [message #126944 is a reply to message #126931]

Wed, 19 March 2008 10:03

Eclipse User

Originally posted by: ck2329.mail.ru

Got it.

As i know binary data transfer fromat is almost ready for deployment - how
can i get it?

I need both Eclipse plugin part and target part for AC and agent.

Re: Porting issue. The Second step. [message #126955 is a reply to message #126931]

Wed, 19 March 2008 10:05

Eclipse User

Originally posted by: ck2329.mail.ru

CG and Heap profilers have less data to transfer - that is why overhead is
not so significant

Re: Porting issue. The Second step. [message #126968 is a reply to message #126944]

Wed, 19 March 2008 10:41

Eclipse User

Andrew V. Novoselsky wrote:
> Got it.
> As i know binary data transfer fromat is almost ready for deployment -
> how can i get it?
>
> I need both Eclipse plugin part and target part for AC and agent.
>

Binary Data transfer should be in the TPTP 4.5 (HEAD) branch. I am not
sure about the status. Please check the following Bugzilla for more
information (be sure to check dependent bugs as well):
https://bugs.eclipse.org/bugs/show_bug.cgi?id=196713

It contains patches that you can probably use.

Regards,
Asaf

--
Asaf Yaffe
Eclipse TPTP Committer, JVMTI Profiler

Re: Porting issue. The Second step. [message #127027 is a reply to message #126968]

Thu, 20 March 2008 02:50

Eclipse User

Originally posted by: ck2329.mail.ru

I would like to perform following experiment:

I want to turn off all data transfer and check execution time in case of
internal (jvmti profiler) operations. What function should i stub for this?

Some more explanations - i want to leave only martini and some more
internal processing for JVM events. I want to exclude all XML related
operations. I need i t do determine if the great overhead is brought only
by XML or if some other(intenal) parts also bring some perfomance bottle
necks.

Re: Porting issue. The Second step. [message #127153 is a reply to message #127027]

Fri, 21 March 2008 03:03

Eclipse User

Hi Andrew,
To suppress data transfer you can profile in standalone mode.
To eliminate writing costs you can try to use /dev/null as trace output
file.
If you intend to turn off XML producing, you can comment it in
JPIAgent/PrintXML module.
Regards,
Igor

Re: Porting issue. The Second step. [message #127166 is a reply to message #127153]

Fri, 21 March 2008 05:16

Eclipse User

Originally posted by: ck2329.mail.ru

Hi Igor

Unfortunately standalone mode is not suitable for our puprpose.

I already made stubs in PrintXML file - according to my rough measurment
on Windows system this doesnt provide significant speed up.
I got follwoing results with thread profiler in standalone mode(just for
test):

without profiling - 4.1 sec
with profiling and xml output - 8.2 sec
with profiling and with stubs in printxml - 7.9

Thats it. I also try to test on our target system asap.

Anyway imho TPTP uses too complicated profiling chain - Eclipse - AC -
profiler - JPI - Martini - JVM ....

Re: Porting issue. The Second step. [message #127178 is a reply to message #127166]

Fri, 21 March 2008 08:17

Eclipse User

Do these numbers take into account initialization phase?
I mean that when profiling is geting started, some time is required for
instrumentation. Afrer that speed of the appication fill be different.

Re: Porting issue. The Second step. [message #127191 is a reply to message #127178]

Fri, 21 March 2008 08:26

Eclipse User

Originally posted by: ck2329.mail.ru

Initialization stage time is excluded from my results.

Re: Porting issue. The Second step. [message #127234 is a reply to message #127191]

Mon, 24 March 2008 07:02

Eclipse User

Andrew V. Novoselsky wrote:
> Initialization stage time is excluded from my results.
>
What version of ThreadProf are you using? Is it the latest 4.5 code that
uses instrumentation for contention analysis, or the 4.4 code that does
not use instrumentation at all?

What is the amount of data created? Can you count the number of events
you get in your test scenarios?

In ThreadProf 4.4, we rely on JVMTI to provide all information and we do
not use instrumentation. For workloads which do not exhibit high monitor
contention, the overhead of the Martini layer itself should not be more
than 20-50%.

Thanks,
Asaf

--
Asaf Yaffe
Eclipse TPTP Committer, JVMTI Profiler

Previous Topic:	TPTP Agent Controller is unavailable under port 10002.
Next Topic:	TPTP all-in-one package for WINDOWS-64

Goto Forum:

-=] Back to Top [=-

Current Time: Sat Jul 19 10:23:31 EDT 2025

.:: Contact :: Home ::.

Breadcrumbs

Sign up to our Newsletter