CodeBuilder.loadParameter and loadReceiver

[Brian Goetz]

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/classfile-api-dev/attachments/20230430/d082d1d6/attachment-0001.htm>