Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
[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 

Attachment: SampleTrace.xml
Description: Binary data


Back to the top