RFR: 8303374: Compiler Implementation for Primitive types in patterns, instanceof, and switch (Preview) [v3]

Aggelos Biboudis abimpoudis at openjdk.org
Thu Oct 5 08:21:07 UTC 2023


On Tue, 3 Oct 2023 09:05:17 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Lower.java line 2982:
>> 
>>> 2980:                     // =>
>>> 2981:                     // if (let tmp$123 = v; ExactnessChecks.int_float(tmp$123))
>>> 2982:                     JCIdent argument = make.Ident(dollar_s);
>> 
>> In principle you don't need a synthetic variable here... (but it's ok if you prefer to leave for uniformity)
>
> Aren't there cases here where the type of the expr is unconditional w.r.t. the type of the pattern (and so, no test is required) ? Perhaps the case I'm thinking of is dealt with one of the ifs at the beginning of this method.
> 
> I have to say I'm a bit confused by how this method is arranged. From a logical perspective I would expect first and foremost to test if the pattern type is a primitive, because that's the only case where Lower needs to do anything (right?).
> 
> Then you can have two cases: the expression has a reference type, in which case you need null check and unboxing. Or the expression has a primitive type.
> 
> In both cases you can be in a situation where the conversion is provably exact, so no need to call the exactness routine - or you can be in an inexact situation where a runtime test is required.
> 
> While I'm sure that is what happens in the above code, I think perhaps the various tests could be arranged in a way to make the above structure pop out a little more?

Refactoring attempt No. 1 complete. I need to recheck the completeness of `checkUnconditionallyExact`. In a following commit.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15638#discussion_r1346993616


More information about the core-libs-dev mailing list