Currently, Type::join is implemented using Type::dual. The idea seems to be that the dual of a join would be the meet of the duals of the operands. This helps us avoid the need to implement a separate join operation. The comments also discuss the symmetry of the join and the meet operations, which seem to refer to the various fundamental laws of set union and intersection.
However, it requires us to find a representation of a Type class that is symmetric, which may not always be possible without outright dividing its value set into the normal set and the dual set, and effectively implementing join and meet separately (e.g. TypeInt and TypeLong).
In other cases, the existence of dual types introduces additional values into the value set of a Type class. For example, a pointer can be a nullable pointer (BotPTR), a not-null pointer (NotNull), a not-null constant (Constant), a null constant (Null), an impossible value (TopPTR), and AnyNull? This is really hard to conceptualize even when we know that AnyNull is the dual of NotNull. It also does not really work, which leads to us sprinkling above_centerline checks all over the place. Additionally, the number of combinations in a meet increases quadratically with respect to the number of instances of a Type. This makes the already hard problem of meeting 2 complicated sets a nightmare to understand.
As a result, it is much profitable to refactor the implementation of Type::join into a separate method instead of trying to cramp it into Type::meet.
However, it requires us to find a representation of a Type class that is symmetric, which may not always be possible without outright dividing its value set into the normal set and the dual set, and effectively implementing join and meet separately (e.g. TypeInt and TypeLong).
In other cases, the existence of dual types introduces additional values into the value set of a Type class. For example, a pointer can be a nullable pointer (BotPTR), a not-null pointer (NotNull), a not-null constant (Constant), a null constant (Null), an impossible value (TopPTR), and AnyNull? This is really hard to conceptualize even when we know that AnyNull is the dual of NotNull. It also does not really work, which leads to us sprinkling above_centerline checks all over the place. Additionally, the number of combinations in a meet increases quadratically with respect to the number of instances of a Type. This makes the already hard problem of meeting 2 complicated sets a nightmare to understand.
As a result, it is much profitable to refactor the implementation of Type::join into a separate method instead of trying to cramp it into Type::meet.
- links to
-
Review(master)
openjdk/jdk/28051