Value
Related Doc:
package ValuesDomain
The computational type of the value.
The computational type of the value.
The precise computational type is needed by the framework to calculate the effect
of generic stack manipulation instructions (e.g., DUP_... and SWAP)
on the stack as well as to calculate the jump targets of RET
instructions and to determine which values are actually copied by, e.g., the
dup_XX instructions.
The computational type has to be precise/correct.
Joins this value and the given value.
Joins this value and the given value.
Join is called whenever an instruction is evaluated more than once and, hence,
the values found on the paths need to be joined. This method is, however,
only called if the two values are two different objects
((this ne value) === true), but both values have the
same computational type.
This basically implements the join operator of complete lattices.
For example, joining a DomainValue that represents the integer value 0
with a DomainValue that represents the integer value 1 may return a new
DomainValue that precisely captures the range [0..1] or that captures
all positive integer values or just some integer value.
this value is always the value that was previously used to
perform subsequent computations/analyses. Hence, if this value subsumes
the given value, the result has to be either NoUpdate or a
MetaInformationUpdate.
In case that the given value subsumes this value, the result has to be
a StructuralUpdate with the given value as the new value. Hence,
this join operation is not commutative. If a new (more abstract)
abstract value is created that represents both values the result always has to
be a StructuralUpdate.
If the result is a StructuralUpdate the framework will continue with the
interpretation.
The termination of the abstract interpretation directly depends on the fact that at some point all (abstract) values are fixed and don't change anymore. Hence, it is important that the type of the update is only a org.opalj.ai.StructuralUpdate if the value has changed in a way relevant for future computations/analyses involving this value. In other words, when two values are joined it has to be ensured that no fall back to a previous value occurs. E.g., if you join the existing integer value 0 and the given value 1 and the result would be 1, then it must be ensured that a subsequent join with the value 0 will not result in the value 0 again.
Conceptually, the join of an object with itself has to return the object
itself. Note, that this is a conceptual requirement as such a call
(this.doJoin(..,this)) will not be performed by the abstract interpretation
framework; this case is handled by the join method.
However, if the join object is also used by the implementation of the domain
itself, it may be necessary to explicitly handle self-joins.
In general, the domain should try to minimize the number of objects that it
uses to represent values. That is, two values that are conceptually equal
should – whenever possible – use only one object. This has a significant
impact on functions such as join.
The program counter of the instruction where the paths converge.
The "new" domain value with which this domain value should be
joined.
The given value and this value are guaranteed to have
the same computational type, but are not reference equal.
Creates a summary of this value.
Creates a summary of this value.
In general, creating a summary of a value may be useful/required
for values that are potentially returned by a called method and which
will then be used by the calling method. For example,
it may be useful to precisely track the flow of values within a method to
be able to distinguish between all sources of a value (E.g., to be able to
distinguish between a NullPointerException created by instruction A and another
one created by instruction B (A != B).) However, from the caller perspective
it may be absolutely irrelevant where/how the value was created in the called
method and, hence, keeping all information would just waste memory and
a summary may be sufficient.
This method is predefined to facilitate the development of project-wide analyses.
Returns true iff the abstract state represented by this value
abstracts over the state of the given value.
Returns true iff the abstract state represented by this value
abstracts over the state of the given value. In other
words if every possible runtime value represented by the given value
is also represented by this value.
The abstract state generally encompasses every information that would
be considered during a join of this value and the other value and that
could lead to a StructuralUpdate.
This method is reflexive, I.e., every value abstracts over itself.
TheIllegalValue only abstracts over itself.
The default implementation relies on this domain value's join method.
Overriding this method is, hence, primarily meaningful for performance reasons.
isMorePreciseThan
Adapts this value to the given domain (default: throws a domain exception that adaptation is not supported).
Adapts this value to the given domain (default: throws a domain exception
that adaptation is not supported). This method needs to be overridden
by concrete Value classes to support the adaptation for a specific domain.
Supporting the adapt method is primarily necessary when you want to
analyze a method that is called by the currently analyzed method
and you need to adapt this domain's values (the actual parameters of the method)
to the domain used for analyzing the called method.
Additionally, the adapt method is OPAL's main mechanism to enable dynamic
domain-adaptation. I.e., to make it possible to change the abstract domain at
runtime if the analysis time takes too long using a (more) precise domain.
The abstract interpretation framework does not use/call this method. This method is solely predefined to facilitate the development of project-wide analyses.
Returns true iff the abstract state represented by this value
is striclty more precise than the state of the given value.
Returns true iff the abstract state represented by this value
is striclty more precise than the state of the given value. In other
words if every possible runtime value represented by this value
is also represented by the given value, but both are not equal;
in other words, this method is irreflexive.
The considered abstract state generally encompasses every
information that would be considered during a join of this
value and the other value and that could lead to a
StructuralUpdate.
Another DomainValue with the same computational
type as this value.
(The IllegalValue has no computational type and, hence,
a comparison with an IllegalValue is not well defined.)
It is recommended to overwrite this method for performance reasons, as the default implementation relies on join.
abstractsOver
Checks that the given value and this value are compatible with regard to its computational type and – if so – calls doJoin.
Checks that the given value and this value are compatible with regard to its computational type and – if so – calls doJoin.
See doJoin(PC,DomainValue) for details.
The program counter of the instruction where the paths converge.
The "new" domain value with which this domain value should be
joined. The caller has to ensure that the given value and this value
are guaranteed to be two different objects.
MetaInformationUpdateIllegalValue or the result of calling doJoin.
It is in general not recommended/needed to override this method.
Abstracts over a concrete operand stack value or a value stored in one of the local variables/registers.
Use Of Value/Dependencies On Value
In general, subclasses and users of a
Domainshould not have/declare a direct dependency onValue. Instead they should useDomainValueas otherwise extensibility of aDomainmay be hampered or even be impossible. The only exceptions are, of course, classes that directly inherit from this class.Refining Value
If you directly extend/refine this trait (i.e., in a subclass of the
Domaintrait you write something liketrait Value extends super.Value), make sure that you also extend all classes/traits that inherit from this type (this may require a deep mixin composition and that you refine the typeDomainTypeaccordingly). However, OPAL was designed such that extending this class should – in general – not be necessary. It may also be easier to encode the desired semantics – as far as possible – as part of the domain.Implementing Value
Standard inheritance from this trait is always supported and is the primary mechanism to model an abstract domain's lattice w.r.t. some special type of value. In general, the implementation should try to avoid creating new instances of values unless strictly required to model the domain's semantics. This will greatly improve the overall performance as this framework heavily uses reference-based equality checks to speed up the evaluation.
OPAL does not rely on any special equality semantics w.r.t. values and never directly or indirectly calls a
Value'sequalsoreqmethod. Hence, a domain can encode equality such that it best fits its need. However, some of the provided domains rely on the following semantics for equals: Two domain values have to be equal (==) iff they represent the same information. This includes additional information, such as, the value of the origin. E.g., a value (AnIntegerValue) that represents an arbitraryIntegervalue has to returntrueif the domain value with which it is compared also represents an arbitraryIntegervalue (AnIntegerValue). However, it may still be necessary to use multiple objects to represent an arbitrary integer value if, e.g., constraints should be attached to specific values. For example, after a comparison of an integer value with a predefined value (e.g.,AnIntegerValue < 4) it is possible to constrain the respective value on the subsequent paths (< 4 on one path and >= 4 on the other path). To make that possible, it is however necessary to distinguish theAnIntegervaluefrom some otherAnIntegerValueto avoid constraining unrelated values.public void foo(int a,int b) { if(a < 4) { z = a - 2 // here a is constrained (< 4), b and z are unconstrained } else { z = a + 2 // here a is constrained (>= 4), b and z are unconstrained } }In general,
equalsis only defined for values belonging to the same domain. If values need to be compared across domains, they need to be adapted to a target domain first.