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.

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.

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

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

If set to true no new computations will be scheduled and running computations will be terminated. Afterwards, the store can be queried, but no new computations can be started.

Returns all entities which have a property of the respective kind. The result is undefined if this method is called while the property store still performs (concurrent) computations.

Returns all entities that currently have the given property bounds based on an "==" (equals) comparison. (In case of final properties the bounds are equal.) If some analysis only computes an upper or a lower bound and no final results exists, that entity will be ignored.

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

Executes the given function at some point between now and the return of a subsequent call of waitOnPhaseCompletion.

The number of times a fallback property was computed for an entity though an (eager) analysis was actually scheduled.

Returns all final entities with the given property.

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). 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.

Returns the property of the respective property kind pk currently associated with the given element e. Does not trigger any computations.

Returns the information stored in the store and removes the key, if any.

This method is thread-safe. However, the client which adds information to the store has to ensure that the overall process of adding/querying/removing is well defined and the ordered is ensured.

Returns the information stored in the store, if any.

This method is thread-safe. However, the client which adds information to the store has to ensure that the overall process of adding/querying/removing is well defined and the ordered is ensured.

Attaches or returns some information associated with the property store using a key object.

This method is thread-safe. However, the client which adds information to the store has to ensure that the overall process of adding/querying/removing is well defined and the ordered is ensured.

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. *

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

true if entities with a specific property kind (EP) may have dependers with suppressed notifications. (I.e., suppressInteriumUpdates("depender")("EP") is true.)

Returns true if the store does not perform any computations at the time of this method call.

This method is only intended to support bug detection.

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 because the entity was queried.

The set of computations that will only be scheduled if the result is required.

Called when a new phase was initialized. Intended to be overridden by subclasses if special handling is required.

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

Associates the given entity with the newly computed intermediate property P.

Calling this method is only supported before any analysis is scheduled!

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

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.

If a property is queried for which we have no value, then this information is used to determine which kind of fallback is required.

Used to identify situations where a property is queried, which is only going to be computed in the future - in this case, the specification of an analysis is broken!

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, a PartialResult or a NoResult.

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

Calling registerLazyPropertyComputation is only supported as long as the store is not queried and no computations are already running. In general, this requires that lazy property computations are scheduled before any eager analysis that potentially reads the value.

Registers a total function that takes a given final property and computes a new final property of a different kind; the function must not query the property store. Furthermore, setupPhase must specify that notifications about interim updates have to be suppressed. A transformer is conceptually a special kind of lazy analysis.

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.

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.

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

The number of (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.

Associates the given property p, which has property kind pk, with the given entity e iff e has no property of the respective kind. The set property is always final.

Calling this method is only supported before any analysis is scheduled!

One 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. A second use case are (eager or lazy) analyses, which want to store some pre-configured information in the property store; e.g., properties of natives methods which were derived beforehand.

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 information is used to decide when we use a fallback and which kind of fallback.

Should be called when a PropertyStore is no longer going to be used to schedule computations.

Properties can still be queried after shutdown.

Reports core statistics; this method is only guaranteed to report final results if it is called while the store is quiescent.

The order in which the property kinds will be finalized; the last phase is considered the clean-up phase and will contain all remaining properties that were not explicitly finalized previously.

Returns a consistent snapshot of the stored properties.

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

The set of transformers that will only be executed when required.

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, will be identified and the fallback value will be used. After that, the remaining intermediate values will be made final.