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

[Martin Boag <martin.boag@xxxxxxxxxx>]

Hi

I'd like to share some experience from
an implementation outside of Hyades that used BCI data collection for gathering
parameter and return information to assist the users identifying performance
problems that were data sensitive.

• Indeed it is not always save to call toString(), and user classes can implement this method to be stateful with side effects that can be harmful is used by instrumentation.
  
  To this end our instrumentation would only call toString() on native classes. The call would only be made on other classes if explicitly configured by the user.
  
  Additionally we had considered allowing for specification of a "safe trace" method that would be called by reflection. However this obviously puts more onus on the user as they specify the instrumentation for there applications under test.
  
• The instrumentation was also specialized for methods that implemented the SQL interface and specifically mined the SQL statement and data source on these. This approach of being able to automatically extract contextual information and place it into a text container associated with the method invocation was very helpful to the end users diagnosis of the application, and has the great advantage of not needing detailed setup by the user.
  
  In this case we also provided some meta information so that the UI could be specialized for the presentation of this SQL call.
  
• One wider point to be aware of providing instrumentation that can see the values being passed applications by parameters can become a security issue when working in a production installations
  
• Methods that exit with exception are also often of interest when profiling - and being able to provide information about the exception being passed is helpful.
  
  Using the return value slot for this information is the approach we used - but again an additional "flag" on the method invocation data was need to indicate that the method was exiting via an exception rather than a normal return.
  
  In my opinion attempting to identify the point of return from methods in general is probably beyond the scope of profiling
  

Regards

        Martin

Marius Slavescu <slavescu@xxxxxxxxxx>
Sent by: hyades-dev-admin@xxxxxxxxxxx

30/08/2004 19:42

Please respond to
hyades-dev

To	hyades-dev@xxxxxxxxxxx
cc
Subject	Re: [hyades-dev] Re: Parameter values on method calls

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)