Hostname: page-component-6766d58669-vgfm9 Total loading time: 0 Render date: 2026-05-14T11:41:44.759Z Has data issue: false hasContentIssue false

The role of linearity in sharing analysis

Published online by Cambridge University Press:  14 June 2022

Gianluca Amato
Affiliation:
University of Chieti–Pescara, Pescara, Italy
Maria Chiara Meo
Affiliation:
University of Chieti–Pescara, Pescara, Italy
Francesca Scozzari*
Affiliation:
University of Chieti–Pescara, Pescara, Italy
*
*Corresponding author. Email: francesca.scozzari@unich.it
Rights & Permissions [Opens in a new window]

Abstract

Sharing analysis is used to statically discover data structures which may overlap in object-oriented programs. Using the abstract interpretation framework, we show that sharing analysis greatly benefits from linearity information. A variable is linear in a program state when different field paths starting from it always reach different objects. We propose a graph-based abstract domain which can represent aliasing, linearity, and sharing information and define all the necessary abstract operators for the analysis of a Java-like language.

Information

Type
Paper
Creative Commons
Creative Common License - CCCreative Common License - BY
This is an Open Access article, distributed under the terms of the Creative Commons Attribution licence (http://creativecommons.org/licenses/by/4.0/), which permits unrestricted re-use, distribution and reproduction, provided the original article is properly cited.
Copyright
© The Author(s), 2022. Published by Cambridge University Press
Figure 0

Figure 1. Two concrete states illustrating pair sharing.

Figure 1

Figure 2. Abstractions of the concrete states in Figure 1.

Figure 2

Figure 3. Three concrete states illustrating nullness and aliasing.

Figure 3

Figure 4. Abstraction of the concrete states in Figure 3. Both $v_1$ and $v_2$ are first level nodes, even if there is an edge pointing to $v_1$.

Figure 4

Figure 5. Concrete and abstract states illustrating aliasing.

Figure 5

Figure 6. A concrete state illustrating nonlinearity.

Figure 6

Figure 7. Abstraction of the concrete state in Figure 6.

Figure 7

Figure 8. The example program.

Figure 8

Figure 9. Two $\mathsf{ALPS}$ graphs for the example program.

Figure 9

Figure 10. A concrete state with variables $v_7,v_8$.

Figure 10

Figure 11. Abstraction of the concrete state in Figure 10.

Figure 11

Figure 12. A pre-aliasing graph for the type environment in Example 36.

Figure 12

Figure 13. Comparison of aliasing graphs. We have explicitly annotated each node with its identity.

Figure 13

Figure 14. Least upper bound of aliasing graphs.

Figure 14

Figure 15. Greatest lower bound of aliasing graphs.

Figure 15

Figure 16. Two pre-$\mathsf{ALPS}$ graphs with a loop and a concrete state which is in the concretization of the Pre-$\mathsf{ALPS}$ graphs $\mathbb{G}$ in Figure 16B.

Figure 16

Figure 17. Example of an $\mathsf{ALPS}$ graph.

Figure 17

Figure 18. Least upper bound of $\mathsf{ALPS}$ graphs.

Figure 18

Figure 19. Greatest lower bound of $\mathsf{ALPS}$ graphs.

Figure 19

Figure 20. The $\mathsf{ALPS}$ interpretation for expressions.

Figure 20

Figure 21. The $\mathsf{ALPS}$ interpretation for simple commands.

Figure 21

Figure 22. The $\mathsf{ALPS}$ interpretation for assignment to field.

Figure 22

Figure 23. The $\mathsf{ALPS}$ interpretation for method calls. The auxiliary function $match_{v.{\mathord{\mathtt{m}}}}$ is defined later in Figure 24.

Figure 23

Figure 24. The $match_{v.{\mathord{\mathtt{m}}}}$ auxiliary operation.

Figure 24

Figure 25. $\mathsf{ALPS}$ interpretations for the makeTree method.