Class AbstractVariable<T extends AbstractVariable<T>>

java.lang.Object
com.ibm.wala.util.graph.impl.NodeWithNumber
com.ibm.wala.fixpoint.AbstractVariable<T>
All Implemented Interfaces:
IVariable<T>, INodeWithNumber
Direct Known Subclasses:
AbstractIntRegisterMachine.MachineState, AbstractIntStackMachine.MachineState, BitVectorVariable, BooleanVariable, IntSetVariable, NullPointerState, ParameterState, PrefixVariable, TypeVariable
public abstract class AbstractVariable<T extends AbstractVariable<T>> extends NodeWithNumber implements IVariable<T>
Represents a single variable in a fixed-point system.

  • Constructor Details

    • AbstractVariable

      protected AbstractVariable()

  • Method Details

    • equals

      public boolean equals(Object obj)
      Overrides:
      equals in class Object

    • nextHash

      public static int nextHash()
      I know this is theoretically bad. However,
      • we need this to be extremely fast .. it's in the inner loop of lots of stuff.
      • these objects will probably only be hashed with each other AbstractVariables, in which case incrementing hash codes is OK.
      • we want determinism, so we don't want to rely on System.identityHashCode

    • hashCode

      public final int hashCode()
      Overrides:
      hashCode in class Object

    • getOrderNumber

      public int getOrderNumber()
      Description copied from interface: IVariable
      Variables must allow the solver implementation to get/set an order number, which the solver uses to control evaluation order.

      It might be cleaner to hold this on the side, but we cannot tolerate any extra space. TODO: consider moving this functionality to a subinterface?

      Specified by:
      getOrderNumber in interface IVariable<T extends AbstractVariable<T>>
      Returns:
      a number used to order equation evaluation

    • setOrderNumber

      public void setOrderNumber(int orderNumber)
      Description copied from interface: IVariable
      Variables must allow the solver implementation to get/set an order number, which the solver uses to control evaluation order.

      It might be cleaner to hold this on the side, but we cannot tolerate any extra space. TODO: consider moving this functionality to a subinterface?

      Specified by:
      setOrderNumber in interface IVariable<T extends AbstractVariable<T>>