[code-reflection] RFR: Model uninitialized variables [v5]

[Maurizio Cimadamore]

On Thu, 24 Oct 2024 20:02:33 GMT, Paul Sandoz <psandoz at openjdk.org> wrote:

>> Uninitialized variables are currently modeled as if they are variables initialized with a default value.
>> 
>> To directly model uninitialized variables we introduce the undefined value operation. This operation has a result that is an undefined value whose type is the undefined type. Such a value can be used as the init operand of a var operation. Thereby we can distinguish between the modeling of uninitialized variables and variables initialized with a default value.
>> 
>> The approach of using a special value means there are very little changes to code operating on models, and undefined values can be tracked. For example, there were no changes required to the SSA transformation. Although, we should update that transformation to check if a value being used is an unitialized value, and if so throw an exception that the variable is not definitely assigned.
>> 
>> A value of the undefined type holds another value of the undefined type's value type, but we don't know what the actual value is and nor can we obtain it.
>
> Paul Sandoz has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Typo
>  - Cleanups

Interesting approach.
We have discussed (offline) to use a single unknown value w/o a type, whose type is implicitly some kind of bottom type (which sits under both `null` and all primitive types). While that might work, I'm not sure we could express its type as a type element... so that maybe will be more complex than what you have here - where the value has a "regular" Java type.

Overall, my preference would be, I guess, for not having to expose such an alien value in Java models, as users will then have to understand what that is for. In the interpreter case, it seems that working around the absence of a variable value would not be too difficult - in the SSA case it's a little harder (but I'd still subjectively prefer to put the complexity there).

That said, this is more of a subjective option - what you have in the PR looks good for now.

-------------

Marked as reviewed by mcimadamore (Reviewer).

PR Review: https://git.openjdk.org/babylon/pull/263#pullrequestreview-2393771253