About MethodTypeDesc having more than 255 slots

[-]

Hi Vincente,
In https://bugs.openjdk.org/browse/JDK-8223803 you argued that it can
be used to represent descriptor with more than 255 slots and that it
can be used to indify a varargs with more than 255 parameters.

However, this has brought some trouble to the classfile-oriented
usages of MethodTypeDesc: it's somewhat complicated for regular
MethodTypeDesc users to check if the desc is always invalid (must
count the slots manually), and this has an effect to encoding the
downstream MethodHandleDesc in the Classfile API. Most parts of the VM
have assumed there's at most 255 arguments: max stacks, max locals,
and number of arguments to bootstrap methods, so it doesn't help
indify existing bytecode. It also makes
ConstantDesc::resolveConstantDesc unreliable, as all other constant
descriptors exclusively describe constants that are valid.

My proposal is to revive https://bugs.openjdk.org/browse/JDK-8223919
and to enforce the 255-slot limit of MethodTypeDesc on creation (which
shouldn't add a large overhead as we already iterate over the
parameters to check for void).

For your proposed usage of MethodTypeDesc with more than 255 slots, I
recommend resorting to other source-oriented representations of such
general varargs or indify, such as string concatenation, given such a
representation is impossible in the JVM. An 1000-argument method type
descriptor cannot represent how the arguments are going to be grouped
together when it's encoded into bytecode, such as which argument
should go to which argument of the chained call tree. Making
MethodTypeDesc represent such in-source structures provides little
value at the cost of uncertainties of invalid descriptors to bytecode
and constant oriented users.

Thank you for your time. Feel free to offer alternative solutions to
my troubles with bytecode/classfile-oriented usage or point out
problems in my mail. I will be more than glad to hear from you and
respond to your questions.

Chen Liang