[code-reflection] RFR: Bytecode round 12 [v3]

Paul Sandoz psandoz at openjdk.org
Wed Sep 4 15:24:43 UTC 2024


On Wed, 4 Sep 2024 06:35:04 GMT, Adam Sotona <asotona at openjdk.org> wrote:

>> I still don't understand why the second check is needed, traversing the predecessors of `n`'s declaring block. If `n` is not dominated by any values in set `doms` then presumably such traversal has to encounter the entry block? 
>> 
>> The implementation of `Value::isDominatedBy` defers to block domination:
>> 
>>     public boolean isDominatedBy(Value dom) {
>>         if (this == dom) {
>>             return true;
>>         }
>> 
>>         if (declaringBlock() != dom.declaringBlock()) {
>>             return declaringBlock().isDominatedBy(dom.declaringBlock());
>>         }
>> ...
>
> Individual dominations are handled as you describe. It applies for cases like this:
> 
> entry -> var -> var store -> var load
>             \
>               > var store -> var load 
> 
> 
> However following case needs a test for dominant set:
> 
> entry -> var -> var store -> var load
>             \             /
>               > var store
> 
> The var load is not dominated by any individual var store, however it is dominated by them.
> 
> The test should fail for example on following case:
> 
> entry -> var -> var store -> var load
>              \            /     
>                 ---------
> 
> 
> The reason why the second part is focused on blocks only is because ops cannot form a bypass inside one block.

Thanks! Doh, of course, i get it now. I think what you are doing is the equivalent of DA analysis. Perhaps we can rename the method accordingly? e.g., `isDefinitelyAssigned` (noting it does not distinguish between assignment with a default value or non-assignment in source because we don't currently make that distinction in the model).

What does the bytecode verifier do when it encounters bytecode in the last case? I expect the verifier will be enhanced to support the new object initialization protocol.

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

PR Review Comment: https://git.openjdk.org/babylon/pull/219#discussion_r1743998501


More information about the babylon-dev mailing list