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

Adam Sotona asotona at openjdk.org
Wed Nov 6 11:57:42 UTC 2024


On Tue, 5 Nov 2024 19:24:05 GMT, Paul Sandoz <psandoz at openjdk.org> wrote:

>> Adam Sotona has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - TestSmallCorpus reached 3rd round 100% stability, no exceptions, no verification errors
>>  - BytecodeLift fix of followup with unresolved array component types of unknown TypeKind
>
> 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).
I'll definitelly look for better solution.

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

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


More information about the babylon-dev mailing list