Home » Archived » Test and Performance Tools Platform (TPTP) » How to write a profiling backend for the TPTP 4.1 AC?
| |
| Re: How to write a profiling backend for the TPTP 4.1 AC? [message #42867 is a reply to message #42281] |
Fri, 25 November 2005 08:35   |
 Randy D. Smith
Messages: 394
Registered: July 2009 |
Senior Member |
|
|
If you're headed down the "newtechAC" branch, and looking at building an
agent by extending BaseCollectorImpl, your agent sends data to the
client simply by using the sendData function from BaseCollectorImpl.
However, all that assumes you have an Agent Controller (the AC part of
the newtechAC link you've followed). All the underlying complexity is
taken care of for you by the AC. If you're looking to embed the agent in
your emulator itself, you have to figure out how to take the AC along
with you. That is not a trivial task! By default, the AC communicates
with agents through shared memory and named pipes...
If, on the other hand, you want to build your agent on some standard
platform where the AC already exists, you have to get the data from your
emulator to your agent on your standard platform of choice where you're
running the AC. Then it's just a matter of doing the sendData to get it
back to the client.
Realize that the existing profiling agents are based on the RAC (and now
the IAC), and these follow a different model than the one you've found
described in the "new technology Agent Controller" documentation. That
AC is moving from "preview technology" (in 4.0) to public status (in
4.1), and is slated to become the AC for future agent work in 4.2 and
beyond.
--
RDS
Simon Bitschnau wrote:
> I'm programming for an embedded target (Gameboy Advance with ARM
> Microprocessor) and the emulator I use can already profile and put out
> data for the GNU gprof programm. Since the emulator is opensource my
> idea was to rewrite that profiler code by implementing an agent to
> integrate the profiling within eclipse.
> I read a lot about the subject but still have some question to clearify
> a few things.
>
>
> My idea so far:
> I read the document for the Client api:
> http://eclipse.org/tptp/platform/documents/newtechAC/C++API/ TPTP%20Data%20Collection%20Subsytem%20External%20Spec.html
>
> If I understand the AC correctly I need to implement an Agent on the
> basis of BaseCollectorImpl to the emulator. That way the emulator could
> act as an Agent. Than I would need to have Launch configurations that
> start the emulator. Eclipse would than be the client and connect to the
> agent residing in the emulator.
>
> The Agent itself then should send profiling data to the client
> (Eclipse). How is the Data send to the client?
> My target is to reuse as much as possible from the java profiling and
> thats where I'm currently not know how to go on.
> Whats the format the java profile sends it's data to the client and can
> I use it? What namespaces in the TPTP plugins should I take a look into
> to further understand how it works?
>
> Any help would be appriciated. This would be massively cool if it
> integrates with Eclipse :)
>
> greetings
>
> Simon Bitschnau
|
|
|
| Re: How to write a profiling backend for the TPTP 4.1 AC? [message #42898 is a reply to message #42867] |
Fri, 25 November 2005 10:41 |
Simon Bitschnau
Messages: 12
Registered: July 2009 |
Junior Member |
|
|
Thanks for the answer so far. I sill have some questions so though.
The emulator I wish to use runs on Windows and is written in C/C++ wich =
=
means the AC is available.
I may have misunderstood the Agent API but my thought was that I can jus=
t =
add the implementation of my Agent to emulator itself by extending the =
emulator with my own Agent Class.
When the emulator then get started with a specific flag it should =
instanciate that class and call it's registerAgent() function to registe=
r =
the agent to the AC. The flag could be added through the Profiler Launch=
=
configuration.
Later the existing profiling code should be modified to call the sendDat=
a =
function of the Agent instance instead of saving the profiling data to a=
=
file.
There is not public API exported as far as I can see from the =
TimeCollector example. There is the agent class plus the static main tha=
t =
just creates an instance of the agent and registers it to the AC. Wouldn=
't =
it be of no meaning whatever the actual code of the agent resides in the=
=
emulator itself or in a seperate application?
Regarding the IAC. I already saw it mentioned in the newsgroup. As far a=
s =
I understand the IAC jumps in if there is no AC available on the machine=
.. =
Dosen't the way an agent has to be implemented stays the same whatever t=
he =
IAC or the AC controlls it?
Because the IAC esseantially has to take over the AC's work if the AC =
isn't available it should also be able to handle Agent's that target the=
=
AC, right?
greetings
Simon Bitschnau
Am Fri, 25 Nov 2005 09:35:19 +0100 schrieb Randy D. Smith =
<randy.d.smith@intel.com>:
> If you're headed down the "newtechAC" branch, and looking at building =
an =
> agent by extending BaseCollectorImpl, your agent sends data to the =
> client simply by using the sendData function from BaseCollectorImpl.
>
> However, all that assumes you have an Agent Controller (the AC part of=
=
> the newtechAC link you've followed). All the underlying complexity is =
=
> taken care of for you by the AC. If you're looking to embed the agent =
in =
> your emulator itself, you have to figure out how to take the AC along =
=
> with you. That is not a trivial task! By default, the AC communicates =
=
> with agents through shared memory and named pipes...
>
> If, on the other hand, you want to build your agent on some standard =
> platform where the AC already exists, you have to get the data from yo=
ur =
> emulator to your agent on your standard platform of choice where you'r=
e =
> running the AC. Then it's just a matter of doing the sendData to get i=
t =
> back to the client.
>
> Realize that the existing profiling agents are based on the RAC (and n=
ow =
> the IAC), and these follow a different model than the one you've found=
=
> described in the "new technology Agent Controller" documentation. That=
=
> AC is moving from "preview technology" (in 4.0) to public status (in =
> 4.1), and is slated to become the AC for future agent work in 4.2 and =
=
> beyond.
>
> --
> RDS
>
>
> Simon Bitschnau wrote:
>> I'm programming for an embedded target (Gameboy Advance with ARM =
>> Microprocessor) and the emulator I use can already profile and put ou=
t =
>> data for the GNU gprof programm. Since the emulator is opensource my =
=
>> idea was to rewrite that profiler code by implementing an agent to =
>> integrate the profiling within eclipse.
>> I read a lot about the subject but still have some question to cleari=
fy =
>> a few things.
>> My idea so far:
>> I read the document for the Client api: =
>> http://eclipse.org/tptp/platform/documents/newtechAC/C++API/ TPTP%20Da=
ta%20Collection%20Subsytem%20External%20Spec.html =
>> If I understand the AC correctly I need to implement an Agent on the=
=
>> basis of BaseCollectorImpl to the emulator. That way the emulator =
>> could act as an Agent. Than I would need to have Launch configuratio=
ns =
>> that start the emulator. Eclipse would than be the client and connec=
t =
>> to the agent residing in the emulator.
>> The Agent itself then should send profiling data to the client =
>> (Eclipse). How is the Data send to the client?
>> My target is to reuse as much as possible from the java profiling and=
=
>> thats where I'm currently not know how to go on.
>> Whats the format the java profile sends it's data to the client and c=
an =
>> I use it? What namespaces in the TPTP plugins should I take a look =
>> into to further understand how it works?
>> Any help would be appriciated. This would be massively cool if it =
>> integrates with Eclipse :)
>> greetings
>> Simon Bitschnau
|
|
|
| Re: How to write a profiling backend for the TPTP 4.1 AC? [message #43118 is a reply to message #42898] |
Mon, 28 November 2005 05:59 |
Randy D. Smith
Messages: 394
Registered: July 2009 |
Senior Member |
|
|
Emulator -- okay, I understand better now. I've always maintained an
"emulator => hardware support, simulator is totally in software" frame
of reference, but obviously that is not a universal distinction! :-) So
from my perspective, you have a simulator, and it runs on Windows.
Great. You're in good shape. All your assumptions between the second and
third blank lines in this message look correct to me. You've got the
right perspective.
So, as I understand it, your implementation looks like this:
if told to act as agent,
instantiate class which extends BaseCollectorImpl
invoke registerAgent on that class
Later, in data generation code
if you were told to act as agent,
sendData rather than write to where you were.
You might want to handle a few commands to turn on and off data
collection (e.g, your UI might have attach/detach which you will turn
into run/stop commands, and then provide your own run and stop command
handlers to turn on and off your data collection).
The only thing incorrect I see below is the IAC portion. Again, you've
got it right (IAC takes over if AC not available), but the IAC is only
tied to the "old AC" (aka, "the RAC") for release 4.1 ... my
understanding is that the IAC won't be AC compatible before release 4.2.
So if you want the "ease of implementation" you've found as described
throughout our exchanges, you'll need the "new technology AC" running
.... there won't be an IAC option available to you. And yes, it is about
as easy as you've described. What you've done is pretty much what I did
this past quarter porting the PerfmonAgent to work with the new
technology AC replacing its prior RAC usage.
Keep us posted on how it goes! I'd like to hear anything you learn along
the way, and I'm more than happy to help with any questions you might
run into. If they're of general interest, post here. If you think they
might not be of general interest, feel free to e-mail me directly.
--
RDS
Simon Bitschnau wrote:
> Thanks for the answer so far. I sill have some questions so though.
>
> The emulator I wish to use runs on Windows and is written in C/C++ wich
> means the AC is available.
>
> I may have misunderstood the Agent API but my thought was that I can
> just add the implementation of my Agent to emulator itself by extending
> the emulator with my own Agent Class.
> When the emulator then get started with a specific flag it should
> instanciate that class and call it's registerAgent() function to
> register the agent to the AC. The flag could be added through the
> Profiler Launch configuration.
> Later the existing profiling code should be modified to call the
> sendData function of the Agent instance instead of saving the profiling
> data to a file.
> There is not public API exported as far as I can see from the
> TimeCollector example. There is the agent class plus the static main
> that just creates an instance of the agent and registers it to the AC.
> Wouldn't it be of no meaning whatever the actual code of the agent
> resides in the emulator itself or in a seperate application?
>
> Regarding the IAC. I already saw it mentioned in the newsgroup. As far
> as I understand the IAC jumps in if there is no AC available on the
> machine. Dosen't the way an agent has to be implemented stays the same
> whatever the IAC or the AC controlls it?
> Because the IAC esseantially has to take over the AC's work if the AC
> isn't available it should also be able to handle Agent's that target
> the AC, right?
>
> greetings
>
> Simon Bitschnau
>
>
> Am Fri, 25 Nov 2005 09:35:19 +0100 schrieb Randy D. Smith
> <randy.d.smith@intel.com>:
>
>> If you're headed down the "newtechAC" branch, and looking at building
>> an agent by extending BaseCollectorImpl, your agent sends data to
>> the client simply by using the sendData function from BaseCollectorImpl.
>>
>> However, all that assumes you have an Agent Controller (the AC part
>> of the newtechAC link you've followed). All the underlying complexity
>> is taken care of for you by the AC. If you're looking to embed the
>> agent in your emulator itself, you have to figure out how to take the
>> AC along with you. That is not a trivial task! By default, the AC
>> communicates with agents through shared memory and named pipes...
>>
>> If, on the other hand, you want to build your agent on some standard
>> platform where the AC already exists, you have to get the data from
>> your emulator to your agent on your standard platform of choice where
>> you're running the AC. Then it's just a matter of doing the sendData
>> to get it back to the client.
>>
>> Realize that the existing profiling agents are based on the RAC (and
>> now the IAC), and these follow a different model than the one you've
>> found described in the "new technology Agent Controller"
>> documentation. That AC is moving from "preview technology" (in 4.0)
>> to public status (in 4.1), and is slated to become the AC for future
>> agent work in 4.2 and beyond.
>>
>> --
>> RDS
>>
>>
>> Simon Bitschnau wrote:
>>
>>> I'm programming for an embedded target (Gameboy Advance with ARM
>>> Microprocessor) and the emulator I use can already profile and put
>>> out data for the GNU gprof programm. Since the emulator is
>>> opensource my idea was to rewrite that profiler code by
>>> implementing an agent to integrate the profiling within eclipse.
>>> I read a lot about the subject but still have some question to
>>> clearify a few things.
>>> My idea so far:
>>> I read the document for the Client api:
>>> http://eclipse.org/tptp/platform/documents/newtechAC/C++API/ TPTP%20Data%20Collection%20Subsytem%20External%20Spec.html
>>> If I understand the AC correctly I need to implement an Agent on
>>> the basis of BaseCollectorImpl to the emulator. That way the
>>> emulator could act as an Agent. Than I would need to have Launch
>>> configurations that start the emulator. Eclipse would than be the
>>> client and connect to the agent residing in the emulator.
>>> The Agent itself then should send profiling data to the client
>>> (Eclipse). How is the Data send to the client?
>>> My target is to reuse as much as possible from the java profiling
>>> and thats where I'm currently not know how to go on.
>>> Whats the format the java profile sends it's data to the client and
>>> can I use it? What namespaces in the TPTP plugins should I take a
>>> look into to further understand how it works?
>>> Any help would be appriciated. This would be massively cool if it
>>> integrates with Eclipse :)
>>> greetings
>>> Simon Bitschnau
>
>
|
|
|
| Re: How to write a profiling backend for the TPTP 4.1 AC? [message #44799 is a reply to message #43118] |
Mon, 05 December 2005 09:48 |
Simon Bitschnau
Messages: 12
Registered: July 2009 |
Junior Member |
|
|
Thanks for your help, I really apreciate it. I started hacking on it thi=
s =
weekend and some new questions came up.
I wrote a basic Agent implementation that does not send any data yet but=
=
should be capable of handling basic collector commands (stop, run, resum=
e, =
pause).
My questions are about the client side. I took a look at the new =
org.eclipse.tptp.platform.execution api as well as looked at the client =
=
side java profiling code.
So far I made a launch configuration that for now only uses the CMainTab=
=
borowed from CDT to select the project and binary to profile.
In my code I get the node for localhost and use it to connect to the Age=
nt =
controller. I successfully recive the AC and use it's CreateProcess to =
start the simulator.
Once the process is started I make a new CollectorImpl class and supply =
it =
with the AC instance, the name of the Agent and the process created in t=
he =
former step. Then I call StartMonitoring and run.
Starting the process alredy gives me some trouble. It starts it but it =
does not seem to recive the parameters correct. The command should look =
=
like this
VisualBoyAdvance-SDL -a "c:\path\to\binary.elf" so I made it like this.
This is what I used:
String EmuExecutable =3D "VisualBoyAdvance-SDL.exe"; // the full path =
is =
actually read from preference store
String EmuParams =3D "-a \"" + gbaRomPath.toOSString() + "\""; // gbaRom=
Path =
is an IPath to the .elf
IProcess vbaProcess =3D ac.CreateProcess(EmuExecutable, EmuParams);
if(vbaProcess.validateProcesstoLaunch())
{
vbaProcess.launch();
...
}
It actually does start the process but the simulator complains that no =
input file is specified. If I type the command manually using the same =
path's it does actually work. So am I missing something when launching t=
he =
process?
What else do I need to do? I know I have to register a listener but I'm =
=
not sure however there are already listeners for java tracing that I can=
=
reuse. I'm also not sure how to bring the agent up in the Eclipse UI. I =
=
found the TraceUIManager wich is used by java profiling but it's interna=
l =
api.
It might be helpfull if I can take a look at how things are done in the =
=
new perfmon plugin. Can I get the source of it somewhere in CVS or =
download it?
Simon Bitschnau
Am Mon, 28 Nov 2005 06:59:22 +0100 schrieb Randy D. Smith =
<randy.d.smith@intel.com>:
> Emulator -- okay, I understand better now. I've always maintained an =
> "emulator =3D> hardware support, simulator is totally in software" fra=
me =
> of reference, but obviously that is not a universal distinction! :-) S=
o =
> from my perspective, you have a simulator, and it runs on Windows. =
> Great. You're in good shape. All your assumptions between the second a=
nd =
> third blank lines in this message look correct to me. You've got the =
> right perspective.
>
> So, as I understand it, your implementation looks like this:
> if told to act as agent,
> instantiate class which extends BaseCollectorImpl
> invoke registerAgent on that class
> Later, in data generation code
> if you were told to act as agent,
> sendData rather than write to where you were.
>
> You might want to handle a few commands to turn on and off data =
> collection (e.g, your UI might have attach/detach which you will turn =
=
> into run/stop commands, and then provide your own run and stop command=
=
> handlers to turn on and off your data collection).
>
> The only thing incorrect I see below is the IAC portion. Again, you've=
=
> got it right (IAC takes over if AC not available), but the IAC is only=
=
> tied to the "old AC" (aka, "the RAC") for release 4.1 ... my =
> understanding is that the IAC won't be AC compatible before release 4.=
2.
>
> So if you want the "ease of implementation" you've found as described =
=
> throughout our exchanges, you'll need the "new technology AC" running =
=
> ... there won't be an IAC option available to you. And yes, it is abou=
t =
> as easy as you've described. What you've done is pretty much what I di=
d =
> this past quarter porting the PerfmonAgent to work with the new =
> technology AC replacing its prior RAC usage.
>
> Keep us posted on how it goes! I'd like to hear anything you learn alo=
ng =
> the way, and I'm more than happy to help with any questions you might =
=
> run into. If they're of general interest, post here. If you think they=
=
> might not be of general interest, feel free to e-mail me directly.
> --
> RDS
>
>
> Simon Bitschnau wrote:
>> Thanks for the answer so far. I sill have some questions so though.
>> The emulator I wish to use runs on Windows and is written in =
>> C/C++ wich means the AC is available.
>> I may have misunderstood the Agent API but my thought was that I can=
=
>> just add the implementation of my Agent to emulator itself by =
>> extending the emulator with my own Agent Class.
>> When the emulator then get started with a specific flag it should =
>> instanciate that class and call it's registerAgent() function to =
>> register the agent to the AC. The flag could be added through the =
>> Profiler Launch configuration.
>> Later the existing profiling code should be modified to call the =
>> sendData function of the Agent instance instead of saving the =
>> profiling data to a file.
>> There is not public API exported as far as I can see from the =
>> TimeCollector example. There is the agent class plus the static main =
=
>> that just creates an instance of the agent and registers it to the A=
C. =
>> Wouldn't it be of no meaning whatever the actual code of the agent =
>> resides in the emulator itself or in a seperate application?
>> Regarding the IAC. I already saw it mentioned in the newsgroup. As f=
ar =
>> as I understand the IAC jumps in if there is no AC available on the =
=
>> machine. Dosen't the way an agent has to be implemented stays the sa=
me =
>> whatever the IAC or the AC controlls it?
>> Because the IAC esseantially has to take over the AC's work if the AC=
=
>> isn't available it should also be able to handle Agent's that target =
=
>> the AC, right?
>> greetings
>> Simon Bitschnau
>> Am Fri, 25 Nov 2005 09:35:19 +0100 schrieb Randy D. Smith =
>> <randy.d.smith@intel.com>:
>>
>>> If you're headed down the "newtechAC" branch, and looking at buildin=
g =
>>> an agent by extending BaseCollectorImpl, your agent sends data to =
>>> the client simply by using the sendData function from =
>>> BaseCollectorImpl.
>>>
>>> However, all that assumes you have an Agent Controller (the AC part =
=
>>> of the newtechAC link you've followed). All the underlying complexi=
ty =
>>> is taken care of for you by the AC. If you're looking to embed the =
=
>>> agent in your emulator itself, you have to figure out how to take t=
he =
>>> AC along with you. That is not a trivial task! By default, the AC =
>>> communicates with agents through shared memory and named pipes...
>>>
>>> If, on the other hand, you want to build your agent on some standard=
=
>>> platform where the AC already exists, you have to get the data from =
=
>>> your emulator to your agent on your standard platform of choice whe=
re =
>>> you're running the AC. Then it's just a matter of doing the sendDat=
a =
>>> to get it back to the client.
>>>
>>> Realize that the existing profiling agents are based on the RAC (and=
=
>>> now the IAC), and these follow a different model than the one you'v=
e =
>>> found described in the "new technology Agent Controller" =
>>> documentation. That AC is moving from "preview technology" (in 4.0)=
=
>>> to public status (in 4.1), and is slated to become the AC for futur=
e =
>>> agent work in 4.2 and beyond.
>>>
>>> -- RDS
>>>
>>>
>>> Simon Bitschnau wrote:
>>>
>>>> I'm programming for an embedded target (Gameboy Advance with ARM =
=
>>>> Microprocessor) and the emulator I use can already profile and put =
=
>>>> out data for the GNU gprof programm. Since the emulator is =
>>>> opensource my idea was to rewrite that profiler code by =
>>>> implementing an agent to integrate the profiling within eclipse.
>>>> I read a lot about the subject but still have some question to =
>>>> clearify a few things.
>>>> My idea so far:
>>>> I read the document for the Client api: =
>>>> http://eclipse.org/tptp/platform/documents/newtechAC/C++API/ TPTP%20=
Data%20Collection%20Subsytem%20External%20Spec.html =
>>>> If I understand the AC correctly I need to implement an Agent on =
>>>> the basis of BaseCollectorImpl to the emulator. That way the =
>>>> emulator could act as an Agent. Than I would need to have Launch =
=
>>>> configurations that start the emulator. Eclipse would than be the=
=
>>>> client and connect to the agent residing in the emulator.
>>>> The Agent itself then should send profiling data to the client =
>>>> (Eclipse). How is the Data send to the client?
>>>> My target is to reuse as much as possible from the java profiling =
>>>> and thats where I'm currently not know how to go on.
>>>> Whats the format the java profile sends it's data to the client and=
=
>>>> can I use it? What namespaces in the TPTP plugins should I take a=
=
>>>> look into to further understand how it works?
>>>> Any help would be appriciated. This would be massively cool if it =
=
>>>> integrates with Eclipse :)
>>>> greetings
>>>> Simon Bitschnau
>>
|
|
|
| Re: How to write a profiling backend for the TPTP 4.1 AC? [message #44983 is a reply to message #44799] |
Mon, 05 December 2005 23:48 |
Randy D. Smith
Messages: 394
Registered: July 2009 |
Senior Member |
|
|
CreateProcess: Some code I've worked with did a CreateProcess(),
setExecutable(<exePath>), and then set the parameters with
setParameter(<paramString>). (As a side note, this particular code,
which I created as a generic process launcher, then does a
setLocation(<where to run>), getConsole so I can setDataProcessor to
grab the output, and then I launch. A very useful testbed, I find. Right
now I'm using it to test some of this stuff out, and right now I'm
running into "issues"... mostly on the console side of things...)
Presumably there's no difference between that and your approach... if
there is, we probably need to bugzilla it. (So if you try breaking down
the createProcess into the separate steps, let me know if those
behaviors differ, please!)
That leaves the "s as the source of the problem. I was just chatting
with my AC guy, and he agreed that it could potentially be problems if
the quotes aren't going through "correctly" in the XML commands. Based
on what he said and what I see, I think it's *not* going through
correctly, but I have to explore that more.
Are the "s necessary? I presume that it has to do with the pathname
having spaces... any way you can move it somewhere space-less and try it
there minus quotes? (E.g., C:\tmp\binary.elf)
The perfmon plugin is at <
http://www.eclipse.org/downloads/download.php?file=/tptp/4.1 .0/TPTP-4.1.0-200511230100R/org.eclipse.tptp.platform.agentc ontroller.new-TPTP-4.1.0.zip
>. (That is where the "Eclipse Feature Plug-in" link on the TPTP
download page points.) As I recall, Vishnu told me the sources that he
had to modify in the trace/profiling UI to accommodate our PerfmonAgent
are included in the zipfile.
I'll keep digging on this a bit more, but thought I'd get this out in
case you can make some more headway with the above and give me some
additional feedback.
--
RDS
Simon Bitschnau wrote:
> Thanks for your help, I really apreciate it. I started hacking on it
> this weekend and some new questions came up.
> I wrote a basic Agent implementation that does not send any data yet
> but should be capable of handling basic collector commands (stop, run,
> resume, pause).
>
> My questions are about the client side. I took a look at the new
> org.eclipse.tptp.platform.execution api as well as looked at the client
> side java profiling code.
> So far I made a launch configuration that for now only uses the
> CMainTab borowed from CDT to select the project and binary to profile.
> In my code I get the node for localhost and use it to connect to the
> Agent controller. I successfully recive the AC and use it's
> CreateProcess to start the simulator.
> Once the process is started I make a new CollectorImpl class and supply
> it with the AC instance, the name of the Agent and the process created
> in the former step. Then I call StartMonitoring and run.
>
> Starting the process alredy gives me some trouble. It starts it but it
> does not seem to recive the parameters correct. The command should look
> like this
> VisualBoyAdvance-SDL -a "c:\path\to\binary.elf" so I made it like this.
>
> This is what I used:
>
> String EmuExecutable = "VisualBoyAdvance-SDL.exe"; // the full
> path is actually read from preference store
> String EmuParams = "-a \"" + gbaRomPath.toOSString() + "\""; //
> gbaRomPath is an IPath to the .elf
>
> IProcess vbaProcess = ac.CreateProcess(EmuExecutable, EmuParams);
> if(vbaProcess.validateProcesstoLaunch())
> {
> vbaProcess.launch();
> ...
> }
>
> It actually does start the process but the simulator complains that no
> input file is specified. If I type the command manually using the same
> path's it does actually work. So am I missing something when launching
> the process?
>
> What else do I need to do? I know I have to register a listener but I'm
> not sure however there are already listeners for java tracing that I
> can reuse. I'm also not sure how to bring the agent up in the Eclipse
> UI. I found the TraceUIManager wich is used by java profiling but it's
> internal api.
>
> It might be helpfull if I can take a look at how things are done in the
> new perfmon plugin. Can I get the source of it somewhere in CVS or
> download it?
>
> Simon Bitschnau
>
>
> Am Mon, 28 Nov 2005 06:59:22 +0100 schrieb Randy D. Smith
> <randy.d.smith@intel.com>:
>
>> Emulator -- okay, I understand better now. I've always maintained an
>> "emulator => hardware support, simulator is totally in software"
>> frame of reference, but obviously that is not a universal
>> distinction! :-) So from my perspective, you have a simulator, and it
>> runs on Windows. Great. You're in good shape. All your assumptions
>> between the second and third blank lines in this message look correct
>> to me. You've got the right perspective.
>>
>> So, as I understand it, your implementation looks like this:
>> if told to act as agent,
>> instantiate class which extends BaseCollectorImpl
>> invoke registerAgent on that class
>> Later, in data generation code
>> if you were told to act as agent,
>> sendData rather than write to where you were.
>>
>> You might want to handle a few commands to turn on and off data
>> collection (e.g, your UI might have attach/detach which you will turn
>> into run/stop commands, and then provide your own run and stop
>> command handlers to turn on and off your data collection).
>>
>> The only thing incorrect I see below is the IAC portion. Again,
>> you've got it right (IAC takes over if AC not available), but the IAC
>> is only tied to the "old AC" (aka, "the RAC") for release 4.1 ... my
>> understanding is that the IAC won't be AC compatible before release 4.2.
>>
>> So if you want the "ease of implementation" you've found as described
>> throughout our exchanges, you'll need the "new technology AC" running
>> ... there won't be an IAC option available to you. And yes, it is
>> about as easy as you've described. What you've done is pretty much
>> what I did this past quarter porting the PerfmonAgent to work with
>> the new technology AC replacing its prior RAC usage.
>>
>> Keep us posted on how it goes! I'd like to hear anything you learn
>> along the way, and I'm more than happy to help with any questions you
>> might run into. If they're of general interest, post here. If you
>> think they might not be of general interest, feel free to e-mail me
>> directly.
>> --
>> RDS
>>
>>
>> Simon Bitschnau wrote:
>>
>>> Thanks for the answer so far. I sill have some questions so though.
>>> The emulator I wish to use runs on Windows and is written in C/C++
>>> wich means the AC is available.
>>> I may have misunderstood the Agent API but my thought was that I
>>> can just add the implementation of my Agent to emulator itself by
>>> extending the emulator with my own Agent Class.
>>> When the emulator then get started with a specific flag it should
>>> instanciate that class and call it's registerAgent() function to
>>> register the agent to the AC. The flag could be added through the
>>> Profiler Launch configuration.
>>> Later the existing profiling code should be modified to call the
>>> sendData function of the Agent instance instead of saving the
>>> profiling data to a file.
>>> There is not public API exported as far as I can see from the
>>> TimeCollector example. There is the agent class plus the static main
>>> that just creates an instance of the agent and registers it to the
>>> AC. Wouldn't it be of no meaning whatever the actual code of the
>>> agent resides in the emulator itself or in a seperate application?
>>> Regarding the IAC. I already saw it mentioned in the newsgroup. As
>>> far as I understand the IAC jumps in if there is no AC available on
>>> the machine. Dosen't the way an agent has to be implemented stays
>>> the same whatever the IAC or the AC controlls it?
>>> Because the IAC esseantially has to take over the AC's work if the
>>> AC isn't available it should also be able to handle Agent's that
>>> target the AC, right?
>>> greetings
>>> Simon Bitschnau
>>> Am Fri, 25 Nov 2005 09:35:19 +0100 schrieb Randy D. Smith
>>> <randy.d.smith@intel.com>:
>>>
>>>> If you're headed down the "newtechAC" branch, and looking at
>>>> building an agent by extending BaseCollectorImpl, your agent sends
>>>> data to the client simply by using the sendData function from
>>>> BaseCollectorImpl.
>>>>
>>>> However, all that assumes you have an Agent Controller (the AC part
>>>> of the newtechAC link you've followed). All the underlying
>>>> complexity is taken care of for you by the AC. If you're looking
>>>> to embed the agent in your emulator itself, you have to figure out
>>>> how to take the AC along with you. That is not a trivial task! By
>>>> default, the AC communicates with agents through shared memory and
>>>> named pipes...
>>>>
>>>> If, on the other hand, you want to build your agent on some
>>>> standard platform where the AC already exists, you have to get the
>>>> data from your emulator to your agent on your standard platform of
>>>> choice where you're running the AC. Then it's just a matter of
>>>> doing the sendData to get it back to the client.
>>>>
>>>> Realize that the existing profiling agents are based on the RAC
>>>> (and now the IAC), and these follow a different model than the one
>>>> you've found described in the "new technology Agent Controller"
>>>> documentation. That AC is moving from "preview technology" (in
>>>> 4.0) to public status (in 4.1), and is slated to become the AC for
>>>> future agent work in 4.2 and beyond.
>>>>
>>>> -- RDS
>>>>
>>>>
>>>> Simon Bitschnau wrote:
>>>>
>>>>> I'm programming for an embedded target (Gameboy Advance with ARM
>>>>> Microprocessor) and the emulator I use can already profile and put
>>>>> out data for the GNU gprof programm. Since the emulator is
>>>>> opensource my idea was to rewrite that profiler code by
>>>>> implementing an agent to integrate the profiling within eclipse.
>>>>> I read a lot about the subject but still have some question to
>>>>> clearify a few things.
>>>>> My idea so far:
>>>>> I read the document for the Client api:
>>>>> http://eclipse.org/tptp/platform/documents/newtechAC/C++API/ TPTP%20Data%20Collection%20Subsytem%20External%20Spec.html
>>>>> If I understand the AC correctly I need to implement an Agent on
>>>>> the basis of BaseCollectorImpl to the emulator. That way the
>>>>> emulator could act as an Agent. Than I would need to have Launch
>>>>> configurations that start the emulator. Eclipse would than be
>>>>> the client and connect to the agent residing in the emulator.
>>>>> The Agent itself then should send profiling data to the client
>>>>> (Eclipse). How is the Data send to the client?
>>>>> My target is to reuse as much as possible from the java profiling
>>>>> and thats where I'm currently not know how to go on.
>>>>> Whats the format the java profile sends it's data to the client
>>>>> and can I use it? What namespaces in the TPTP plugins should I
>>>>> take a look into to further understand how it works?
>>>>> Any help would be appriciated. This would be massively cool if
>>>>> it integrates with Eclipse :)
>>>>> greetings
>>>>> Simon Bitschnau
>>>
>>>
>
|
|
|
Goto Forum:
Current Time: Thu Apr 25 15:24:05 GMT 2024
Powered by FUDForum. Page generated in 0.07216 seconds |
] 
Search
Help
Register
Login
Home
