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
