Returns the property of the respective property kind pk currently associated with the given element e.

This is the most basic method to get some property and it is the preferred way if (a) you know that the property is already available – e.g., because some property computation function was strictly run before the current one – or if (b) the property is computed using a lazy property computation - or if (c) it may be possible to compute a final answer even if the property of the entity is not yet available.

Immutable map which stores the context objects given at initialization time.

The set of all entities which already have an entity property state that passes the given filter.

This method returns a snapshot.

Returns all entities that currently have the given property bounds based on an "==" (equals) comparison.. (In case of final properties the bounds are equal.)

Returns all entities which have a property of the respective kind. This method returns a consistent snapshot view of the store w.r.t. the given PropertyKey.

The number of properties that were computed using a fast-track.

Enforce the evaluation of the specified property kind for the given entity, even if the property is computed lazily and no "eager computation" requires the results anymore. Force also ensures that the property is stored in the store even if the fallback value is used. Using force is in particular necessary in cases where a specific analysis should be scheduled lazily because the computed information is not necessary for all entities, but strictly required for some elements. E.g., if you want to compute a property for some piece of code, but not for those elements of the used library that are strictly necessary. For example, if we want to compute the purity of the methods of a specific application, we may have to compute the property for some entities of the libraries, but we don't want to compute them for all.

Processes the result eventually; generally, not directly called by analyses. If this function is directly called, the caller has to ensure that we don't have overlapping results and that the given result is a meaningful update of the previous property associated with the respective entity - if any!

See hasProperty(SomeEPK) for details. *

The number of times a property was directly computed again due to an updated dependee.

Returns true if the given entity is known to the property store. Here, isKnown can mean

• that we actually have a property, or
• a computation is scheduled/running to compute some property, or
• an analysis has a dependency on some (not yet finally computed) property, or
• that the store just eagerly created the data structures necessary to associate properties with the entity.

Returns an iterator of the different properties associated with the given element.

This method is the preferred way to get a snapshot of all properties of an entity and should be used if you know that all properties are already computed. Using this method will not trigger the computation of a property.

The number of times the property store reached quiescence.

Registers a function that lazily computes a property for an element of the store if the property of the respective kind is requested. Hence, a first request of such a property will always first return no result.

The computation is triggered by a(n in)direct call of this store's apply method.

This store ensures that the property computation function pc is never invoked more than once for the same element at the same time. If pc is invoked again for a specific element then only because a dependee has changed!

In general, the result can't be an IncrementalResult and scheduleLazyPropertyComputation cannot be used for properties which should be computed by phased analyses.

A lazy computation must never return a NoResult; if the entity cannot be processed an exception has to be thrown or the bottom value has to be returned.

Setting scheduleLazyPropertyComputation is only supported as long as the store is not queried. In general, this requires that lazy property computations are scheduled before any eager analysis that potentially reads the value.

Registers a property computation that is eagerly triggered when a property of the given kind is derived for some entity for the first time. Note, that the property computation function – as usual – has to be thread safe (only on-update continuation functions are guaranteed to be executed sequentially per E/PK pair). The primary use case is to kick-start the computation of some e/pk as soon as an entity "becomes relevant".

In general, it also possible to have a standard analysis that just queries the properties of the respective entities and which maintains the list of dependees. However, if the list of dependees becomes larger and (at least initially) encompasses a significant fraction or even all entities of a specific kind, the overhead that is generated in the framework becomes very huge. In this case, it is way more efficient to register a triggered computation.

For example, if you want to do some processing (kick-start further computations) related to methods that are reached, it is more efficient to register a property computation that is triggered when a method's Caller property is set. Please note, that the property computation is allowed to query and depend on the property that initially kicked-off the computation in the first place. Querying the property store may in particular be required to identify the reason why the property was set. For example, if the Caller property was set to the fallback due to a depending computation, it may be necessary to distinguish between the case "no callers" and "unknown callers"; in case of the final property "no callers" the result may very well be NoResult.

The number of resolved closed strongly connected components.

Please note, that depending on the implementation strategy and the type of the closed strongly connected component, the resolution of one strongly connected component may require multiple phases. This is in particular true if a cSCC is resolved by committing an arbitrary value as a final value and we have a cSCC which is actually a chain-like cSCC. In the latter case committing a single value as final which just break up the chain, but will otherwise (in case of chains with more than three elements) lead to new cSCCs which the require detection and resolution.

Schedules the execution of the given PropertyComputation function for the given entity. This is of particular interest to start an incremental computation (cf. IncrementalResult) which, e.g., processes the class hierarchy in a top-down manner.

Simple counter of the number of tasks (OnUpdateContinuations) that were executed in response to an updated property.

Simple counter of the number of tasks that were executed to perform an initial computation of a property for some entity.

Directly associates the given property p with property kind pk with the given entity e if e has no property of the respective kind. The set property is always final. The store does not guarantee that the value is set before before a later scheduled analysis is executed. I.e., no guarantee is given that the value is set immediately.

A use case is an analysis that does use the property store while executing the analysis, but which wants to store the results in the store. Such an analysis must be executed before any other analysis is scheduled.

Needs to be called before an analysis is scheduled to inform the property store which properties will be computed now and which are computed in a later phase. The later information is used to decide when we use a fallback.

Core statistics.

Returns a consistent snapshot of the stored properties.

Awaits the completion of all property computations which were previously scheduled. As soon as all initial computations have finished, dependencies on E/P pairs for which no value was computed and also will not be computed in the future(!) (see setupPhase for details), will be identified and the fallback value will be used. After that, cycle resolution will be performed. I.e., first all _closed_ strongly connected components will be identified that do not contain any properties for which we will compute (in a future phase) any more refined values. Then the values will be made final.

If the store is suspended, waitOnPhaseCompletion will return as soon as all running computations are finished. By updating the isSuspended state and calling waitOnPhaseCompletion again computations can be continued.

Returns a snapshot of the properties with the given kind associated with the given entities.

Returns a snapshot of the properties with the given kind associated with the given entities.

Looks up the context object of the given type. This is a comparatively expensive operation; the result should be cached.

If "debug" is true and we have an update related to an ordered property, we will then check if the update is correct!

Returns all final entities with the given property.

Tests if we have a property for the entity with the respective kind. If hasProperty returns true a subsequent apply will return an EPS (not an EPK).

The callback function that is regularly called by the property store to test if the property store should stop executing new tasks. Given that the given method is called frequently, it should be reasonably efficient. The method has to be thread-safe.

The default method tests if the current thread is interrupted.

Suspending the property store will leave the property store in a consistent state and the computation can be continued later on by updating this function (if necessary) and calling waitOnPhaseCompletion again. I.e., interruption can be used for debugging purposes!

Called when the first top-level exception occurs. Intended to be overridden by subclasses.

Registers a function that lazily computes multiple properties of different kinds at the same time for an element of the store.

For further details see registerLazyPropertyComputation.

Will call the given function c for all elements of es in parallel.

Returns a short string representation of the property store showing core figures.