Re: [hyades-dev] Re: Parameter values on method calls

[Marius Slavescu <slavescu@xxxxxxxxxx>]

Some clarifications and suggestions
(especially for the Trace model subgroup):

- in Hyades 3.0.1 we added
(in the last minute) just the support for string based representation of
the 
       
parameters/return values, we can later extend TRCObjectValue and
the corresponding events
       
with other specific/custom representations.
- in my example of the new
elements I just say that we could use the toString() to get the string
based representation, 
       
I don't enforce anybody to do that, we could probably do what the
Eclipse debugger does in this case, 
       
although the producers (especially JVMPI or BCI based profilers)
are free to use any method they find appropriate 
       
(you could even use an XML based serialization so you get a complex
textual representation for the value).
- we don't cover "this"
object yet in method* related events, as Allan mentioned bellow
       
one way to get the initial state of the object might be by looking
at the returnValue of the constructor call 
       
(although -init-/constructors signature specifies void as the return
value), depending on how we structure the 
       
TRCInputOutputEntry.value list we could have "this" in
there also, currently I specified in the model docs the 
       
following rule for the value list [returnValue,param1,param2,...,paramN]
we could have 
       
[returnValue,param1,param2,...,paramN, thisValue] so we just need
to send an extra (last one) parameter 
       
for "this" and handle this appropriately in the viewers;
       
we could also represent the values of both ends (for call-return
and entry-exit) so the rule would be
       
returnValue,param1Start,param2Start,..paramNStart,thisValueStart,param1Stop,param2Stop,..paramNStop,thisValueStop

       
(where start = [call or entry] and stop = [exit or return]).
- we don't have a place to
mark that an invocation exited by an exception, the exception message
       
could be passed as the returnValue because the actual return object
value is not valid anymore in that context;
       
also an interesting use of the TRCFullMethodInvocation.callerLineNo
field (if we rename it and reuse it) could be to 
       
store the returnLineNumber that represent the line where the method
exited (although I'm not sure if JVMPI can give us this info).
- regarding the use of toTraceString(),
I said above that the producer is free to use any method to generate
       
the string base representation of the object value.
- we could share the value
objects if we get the corresponding ID of each parameter/return object,
we currently don't have this information in the
       
model or the corresponding events.

Thanks!
Marius Slavescu

Monday, August 30, 2004
1:15 PM
To: hyades-dev@xxxxxxxxxxx
cc: 
From: Allan K Pratt <apratt@xxxxxxxxxx>
Subject: [hyades-dev] Re:
Parameter values on method calls



Marius, and parameter/return value
people generally:

First, do you realize it's dangerous
to add calls to toString() inside a
program? While testing Probekit we
encountered problems doing this. The
toString() implementation in some classes
can have bugs. Such bugs don't
crash a running program because toString()
is normally never called for
objects of that type. Another situation
is that toString works only when
the object is in certain internal states,
and the normal program never
calls toString when it's not in one
of those states. You'll be adding
calls that occur when it's between
states.

In this discussion, "crashing
the program" can be worse than just throwing
an exception, which you can catch as
part of your agent instrumentation.
It can enter infinite loops, or call
native code with bad arguments, or
alter the state of the object or of
other objects in the system. I realize
that these could be construed as bugs
in the program you're monitoring,
but we never said we could only monitor
bug-free programs. Bottom line:
promiscuous calling of toString() is
not safe. Even just doing it at
"boundary methods" in and
out of a component might be risky.

Also, I are you collecting the toString()
value for the "this" object, for
non-static methods? If not, I think
you should. But remember, "this" isn't
always readable: in constructors it's
not a valid object on entry, only on
exit. Maybe somebody thought it was
implied that the "this" value is the
first argument for all instance methods,
but that won't be obvious to a
Java programmer, only to people familiar
with the underlying JVM
implementation (and C++ implementations).
And the details of "this" values
in constructors, for example, would
be completely lost if they're not
documented.

Also, are you collecting anything,
a marker or even the exception object
toString() value, when a method exits
by exception? I don't see anything
in the model for capturing this.

Also, the value you'd like to see in
a trace isn't necessarily the
"toString()" value. Are we
using reflection to capture this? If so, it
might be nice to use reflection and
see if there's a toTraceString()
method, and call that instead; we can
call toString() if there isn't one.
This way, programmers can provide a
more trace-appropriate string
representation if they choose to -
in particular, a method that reaches
deeper than toString to show interesting
parts of contained objects, like
an SQL query object that contains a
query string. Contrariwise, sometimes
toTraceString will produce *less* information
than toString, knowing that
the trace model is the consumer. Otherwise,
we're overloading toString()
and making it serve too many masters.

Also, for efficiency, should we share
objects when the parameter values
are the same on entry and on exit?
Both lists can refer to the same
TRCObjectValue instance in that case.

-- Allan Pratt, apratt@xxxxxxxxxx
Rational software division of IBM




Marius Slavescu/Toronto/IBM@IBMCA
08/30/2004 07:02 AM

To
Martin Boag <martin.boag@xxxxxxxxxx>
cc
Tanuj Vohra <tvohra@xxxxxxxxxx>,
Harm Sluiman/Toronto/IBM@IBMCA, Allan K
Pratt/Cupertino/IBM@IBMUS, Richard
Duggan/Toronto/IBM@IBMCA
Subject
Re: Parameter values on method calls





Hi Martin,

The new events/elements are:

<parameter value="toString()
parameter value"/>
and
<returnValue value="toString()
return value"/>

which would be sent as child elements
of methodEntry and methodExit
events.

I also modified the trace model loaders
to handle these new elements.

Using the latest Hyades build (3.0.1
or 3.1), try to import (using "Show
full data" option) the following
trace, save the agent then look at the
trciovxmi XMI file to see result (AFAIK
in Hyades there is no view yet
that handles this side of the model):



The first element in the value list
(see TRCInputOutputEntry) is reserved
for the return value (even when the
method is declared with void).

To access the params/return values
you just need to do the following:

TRCInputOutputContainer container =
trcProcess.getInputOutputContainer();
Map map = container.getEntries();
List values = (List)map.get(trcMethodInvocation);
TRCObjectValue returnValue = values.get(0);
TRCObjectValue param1Value = values.get(1);
TRCObjectValue param2Value = values.get(2);
TRCObjectValue param3Value = values.get(3);

For example if param1Value.getStringValue()==null
that means the parameter
value was null.

In the trace events, in order to send
a parameter with a null value (the
second parameter is null) you will
need to send just the parameter element
without a value attribute:

<methodEntry ...>
<parameter value="value1"/>
<parameter/>
<parameter value="value3"/>
</methodEntry>

For return is the same, the return
value is null:
<methodExit...>
<returnValue/>
<parameter value="value1"/>
<parameter/>
<parameter value="value3"/>
</methodEntry>

In the model in order to distinguish
the case where return is void and
when is null you will need to look
at the method signature, it would be to
complicated to have that list with
null entries (at least for now).

Thanks !

Marius Slavescu
Test and Analysis Tool Enablement,
Toronto ADTC
phone:905-413-3610      mailto:slavescu@xxxxxxxxxx
fax:  905-413-4920
IBM Canada Limited.
8200 Warden Ave.
Markham, Ontario L6G 1C7





Martin Boag <martin.boag@xxxxxxxxxx>
08/28/2004 05:47 AM

To
Tanuj Vohra <tvohra@xxxxxxxxxx>,
Marius Slavescu/Toronto/IBM@IBMCA
cc

Subject
Parameter values on method calls







Hi guys,

In Fridays Trace Model meeting I picked
up that there has been a last
minute extension to the model for method
innovation return and call
parameters.

This is good news! - I'm currently
working on building a importer for the
OMEGAMON application trace data to
Hyades model. (We hope to make this
available as a support pack for RPA
v1.0).

In my current implementation I throw
away the method parameter and return
values in the OMEGAMON trace data -
but I should now be loading this new
model extension with that data.

Marius,

Are there extensions to XML4Profiling
for this new data? - my importer is
working by mapping the OMEGAMON data
to XML4Profiling fragments and
feeding them into the existing loaders.

Tanuj,

What visualization does BlueRat provide
for this data?

Thanks

Martin


(See attached file: SampleTrace.xml)
(Attachments removed)