Browse Prior Art Database

Method to predict process's stack using static code analysis

IP.com Disclosure Number: IPCOM000212201D
Publication Date: 2011-Nov-04
Document File: 5 page(s) / 60K

Publishing Venue

The IP.com Prior Art Database

Abstract

Method to predict process stack using static code analysis

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 56% of the total text.

Page 01 of 5

Method to predict process's stack using static code analysis

Man page for procstack : http://publib.boulder.ibm.com/infocenter/aix/v6r1/index.jsp?topic=/com.ibm.aix.cmds/doc/aixcmds4/procst ack.htm

Procstack currently issues a SIGSTOP to the pid whose process stack needs to be studied. This stops all the threads which are executing to preserve uniformity among all the thread's stack. Without stopping, the /proc gets updated and reading the stack may produced undesirable results.

Disadvantage:

The application that is being studied is stopped till the stack is read completely which affects the throughtput of the application. Also when procstack is run on the process repeatedly ( say in a loop) the performance loss is high.

In this disclosure we will look at a novel way to predict the stack of any thread without having to read through the entire stack thus reducing the performance over head of the application under study.

In this method we do a static analysis of the code that needs to be sampled for the stack and generate the call graph for the process. From the call graph we find the minimum level of functions in the process stack that need to be identified to guess the stack.

(eg) main( ) -> f1( ) ->f2( ) . If f2 ( ) is called only in this path, then if we find f2 ( ) to be the top stack we can easily predict the stack.

There are some existing static code analyzers like GNU cflow and frama-c.

http://www.gnu.org/software/cflow/

The Cflow allows the static code flow report to be generated while doing the build by providing options in the makefile.

Advantages:

1. The process that is being studied need not be stopped for a long time and hence the application's performance impact will be less.

2. Since most of the time the code executes in any specific function which does the core calculation and if the call path to that function is unique, this could result in result in the application being stopped for a very little time ( to read the first stack frame alone).


3. The static analysis is done at the beginning and hence if the procstack is run with small intervals the performance impact would be very less on the application.

We would look at the following example.

main ( ) {

F1 ( ) ;

.

.

.

1


Page 02 of 5

F2 ( );

.

.

.

F3 ( );

.

.

}

F1 ( )

{

.

.

}

F2 ( )

{

.

.

}

F3 ( )

{

.

.

}

The static call graph for the code is generated . Which would be similar to

call graph:

2


Page 03 of 5

From the call graph we identify the minimum level of stack depth that is needed to predict the stack accurately. minimum level is specific to each function and it is calculated treating the specific funciton as the top o...