[code-reflection] RFR: Aggregated work on Verifier and BytecodeLift deconstruction

[Adam Sotona]

On Wed, 6 Nov 2024 11:55:19 GMT, Adam Sotona <asotona at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/reflect/code/bytecode/UnresolvedType.java line 51:
>> 
>>> 49:         private static final TypeElement.ExternalizedTypeElement UNRESOLVED_REF = new TypeElement.ExternalizedTypeElement("?REF", List.of());
>>> 50: 
>>> 51:         private JavaType resolved;
>> 
>> Sneaky mutability :-) Not something i would recommend although i understand the convenience. You could instead use a map of unresolved type to resolved type. But let's consider that later as i think there is a broader issue. More generally the transformation of types is harder than it should be, and this is a good use case to help improve this area. I don't have any solid ideas right now but hopefully we can eventually come up with something better.
>
> Yes, this is not ideal. Maps can be used later in the transform, however unresolved component of an unresolved array type is something that needs to be at least partially resolved (2-slot long or double vs 1-slot others) in the first stage of BytecodeLift or it causes stack problems with hybrid single and dual slot instructions (dup_x2, dup2, dup2_x1 and dup2_x2). The problem here is that I cannot retrospectively change types in the middle of a lift process. 
> 
> I'll definitelly look for better solution.

Maybe I can inject an explicit ConvOp after ArrayLoadOp result of an unresolved type, however it will generate an instability. Or custom ResolveTypeOp, which can be later removed by a transform.

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

PR Review Comment: https://git.openjdk.org/babylon/pull/258#discussion_r1830907904