Abstract. We present the main concepts, usage and implementation of SACO, a static analyzer for concurrent objects. Interestingly, SACO is able to infer both liveness (namely termination and resource boundedness) and safety properties (namely deadlock freedom) of programs based on concurrent objects. The system integrates auxiliary analyses such as points-to and may-happen-in-parallel, which are essential for increasing the accuracy of the aforementioned more complex properties. SACO provides accurate information about the dependencies which may introduce deadlocks, loops whose termination is not guaranteed, and upper bounds on the resource consumption of methods.

We present the main concepts, components, and usage of Gasol, a Gas AnalysiS and Optimization tooL for Ethereum smart contracts. Gasol offers a wide variety of cost models that allow inferring the gas consumption associated to selected types of EVM instructions and/or inferring the number of times that such types of bytecode instructions are executed. Among others, we have cost models to measure only storage opcodes, to measure a selected family of gas-consumption opcodes following the Ethereum's classification, to estimate the cost of a selected program line, etc. After choosing the desired cost model and the function of interest, Gasol returns to the user an upper bound of the cost for this function. As the gas consumption is often dominated by the instructions that access the storage, Gasol uses the gas analysis to detect under-optimized storage patterns, and includes an (optional) automatic optimization of the selected function. Our tool can be used within an Eclipse plugin for Solidity which displays the gas and instructions bounds and, when applicable, the gas-optimized Solidity function.

This article presents a novel cost analysis framework for concurrent objects. Concurrent objects form a wellestablished model for distributed concurrent systems. In this model, objects are the concurrency units that communicate among them via asynchronous method calls. Cost analysis aims at automatically approximating the resource consumption of executing a program in terms of its input parameters. While cost analysis for sequential programming languages has received considerable attention, concurrency and distribution have been notably less studied. The main challenges of cost analysis in a concurrent setting are as follows. First, inferring precise size abstractions for data in the program in the presence of shared memory. This information is essential for bounding the number of iterations of loops. Second, distribution suggests that analysis must infer the cost of the diverse distributed components separately. We handle this by means of a novel form of object-sensitive recurrence equations that use cost centres in order to keep the resource usage assigned to the different components separate. We have implemented our analysis and evaluated it on several small applications that are classical examples of concurrent and distributed programming. consider different types of resources of interest. For instance, we can measure traditional cost measures like number of executed instructions or memory consumption. In the former case, we will infer that 3 C elems .7 C hdRead inst C update inst / instructions will be executed. In the expression, elems corresponds to the maximum number of iterations of the loop; at each iteration, seven instructions are executed (the loop condition, the two increments, two method invocations, the get and the await), and the number of instructions of executing methods hdRead and update, denoted hdRead inst and update inst respectively, are added as well. For simplicity, we ignore here the values of the parameters. Besides, three instructions are executed outside the loop. The analysis will need to infer also the cost of the methods hdRead and update and plug them in the aforementioned expression. With regard to memory consumption, a new memory is not created in the loop; hence, we would output an expression of the form elems .hdRead heap C update heap / that relies on the memory created by the invoked methods (denoted hdRead heap and update heap ). Interestingly, we can also consider concurrency-related measures like the number of tasks spawned. In the aforementioned method, we spawn one task directly (but the method invocations might also spawn new tasks transitively). Therefore, we will compute an expression of the form elems .1ChdRead tasks Cupdate tasks / that relies on the number of tasks spawned by the calls to hdRead and update. Observe that the types of resources we have considered are platform independent (unlike WCET or energy consumption), that is, they can be inferred by inspecting the program, and the hardware on which the program will be executed can be ignored. Platform depend...

This article presents parallel cost analysis , a static cost analysis targeting to over-approximate the cost of parallel execution in distributed systems. In contrast to the standard notion of serial cost , parallel cost captures the cost of synchronized tasks executing in parallel by exploiting the true concurrency available in the execution model of distributed processing. True concurrency is challenging for static cost analysis, because the parallelism between tasks needs to be soundly inferred, and the waiting and idle processor times at the different locations need to be accounted for. Parallel cost analysis works in three phases: (1) it performs a block-level analysis to estimate the serial costs of the blocks between synchronization points in the program; (2) it then constructs a distributed flow graph (DFG) to capture the parallelism, the waiting, and idle times at the locations of the distributed system; and (3) the parallel cost can finally be obtained as the path of maximal cost in the DFG. We prove the correctness of the proposed parallel cost analysis, and provide a prototype implementation to perform an experimental evaluation of the accuracy and feasibility of the proposed analysis.

No abstract