CodeBuilder.loadParameter and loadReceiver

[-]

Agreed. Should I create a JBS issue for such a list, or will we just
drop in this dev list and revisit later?

On Sun, Apr 30, 2023 at 4:42 PM Brian Goetz <brian.goetz at oracle.com> wrote:
>
> I believe there is room for lots of higher-level conveniences like this.  We deliberately didn't go down some of these design paths up until now, not because they aren't worthwhile, but because we wanted to focus on making sure the basic substrate is solid.  My preference would be to get the API to preview first with solid test coverage and usage in the JDK of the features we have, and then come back for the next layer in a more organized fashion, after we have a larger base of example code to base this on.  SO my take is that these are good ideas but I'd rather gather a list and then pick from the list later rather than implement each one as they occur to us.
>
> On 4/30/2023 5:35 PM, - wrote:
>
> Since now we decide to cache MethodTypeDesc symbols in MethodInfo to
> reduce creation overheads at stackmap generation, these symbols
> inadvertently, and to our convenience, allow us to more easily load
> method arguments:
>
> Before:
> for (int j = 0; j < mi.desc.parameterCount(); j++) {
>     bcb.loadInstruction(TypeKind.from(mi.desc.parameterType(j)),
> bcb.parameterSlot(j));
> }
>
> Now:
> for (int j = 0; j < mi.desc.parameterCount(); j++) {
>     bcb.loadParameter(j);
> }
>
> Where loadParameter implementation can be: (except delegation implementations)
>
> public CodeBuilder loadParameter(int paramNo) {
>     var kind = TypeKind.from(methodInfo.methodTypeSymbol().parameterType(paramNo));
>     loadInstruction(kind, parameterSlot(paramNo));
>     return this;
> }
>
> Hence, with the implementation changes in 8306842
> https://github.com/openjdk/jdk/pull/13671 that added
> methodInfo.methodTypeSymbol(), we have an opportunity for this more
> convenient method.
>
> Similarly, we can add a "loadReceiver"/"loadThis" that performs
> aload(0) for instance methods and throws for static methods.
>
> Brian, can you evaluate if this is a good addition API-wise? I think
> this new API can cover most usages of the old parameterSlot() calls;
> at least this is the case in 6983726 and 8301703 patches.
>
> Chen Liang
>
>