Checking for 'Stack size mismatch'

Øystein Myhre Andersen o.myhre at gmail.com
Sun Mar 10 15:04:29 UTC 2024


Sorry again: Now I mess up: it's possible like this:

 - At labelBinding what is in the  'come-from' list  is checked
 - With a later backward jump to this label, it is checked again


On Sun, Mar 10, 2024 at 3:54 PM Øystein Myhre Andersen <o.myhre at gmail.com>
wrote:

> Sorry: This does not handle backward jumps.
>
> But   a 'come-from' list  might be useful for the StackMapGenerator.
> And, maybe speed it up.
>
> P.S. In the byte code of Simula, we had the rule that a label only had one
> and only one associated goto.
>
> On Sun, Mar 10, 2024 at 3:21 PM Øystein Myhre Andersen <o.myhre at gmail.com>
> wrote:
>
>>
>> Yes, I know which method builder is called.
>> I have a class file builder like:
>>
>> byte[] bytes = ClassFile.of().build(currentClassDesc(),
>>       classBuilder -> {
>>             classBuilder
>>                   ....
>>                   .withMethodBody("_STM", MTD_STM, ClassFile.ACC_PUBLIC,
>>                         codeBuilder -> buildMethod_STM(codeBuilder));
>>       }
>> );
>>
>> Within 'buildMethod_STM' I traverse a syntax tree building code from each
>> node.
>> Somewhere there a mistake is made that leads to 'stack size mismatch'.
>>
>> When I return from 'buildMethod_STM', the method builder will finalize
>> its work.
>> It generates the bytecode and builds the stack map table.
>> I assume that it checks the stack size at all labels, it must do so to
>> build a correct stack map table.
>>
>> Along with the error message comes a complete dump of the entire method.
>>
>> Checking for 'Stack size mismatch' is currently done in
>> 'java.base/jdk.internal.classfile.impl.StackMapGenerator'.
>> It would have been nice if this was tested earlier by Codebuilder when
>> the labelBinding pseudo instruction was created.
>>
>> One way it might be done is to build a 'come-from' list within
>> labelBinding pseudo instruction.
>>
>> On Sat, Mar 9, 2024 at 10:10 PM - <liangchenblue at gmail.com> wrote:
>>
>>> What are you trying to do? So you are writing a class and there's a
>>> stack size error, but you don't know which method builder this stack size
>>> error is from?
>>>
>>> On Sat, Mar 9, 2024 at 2:04 PM Øystein Myhre Andersen <o.myhre at gmail.com>
>>> wrote:
>>>
>>>> You said:  as this error can only be detected at run time.
>>>> That is wrong. It occurs when building stack-map.
>>>>
>>>> On Sat, Mar 9, 2024 at 7:38 PM - <liangchenblue at gmail.com> wrote:
>>>>
>>>>> Hi Øystein,
>>>>> ClassFile API does not always ensure the created bytecode is
>>>>> valid, and allowing creation of code with invalid stack size is a feature
>>>>> instead of a bug. A stack size mismatch problem, in essence, is closer to
>>>>> the error which a user forgot to call a builder method. And putting this
>>>>> check earlier doesn't really help, as this error can only be detected at
>>>>> run time. You can always use ClassFile.verify to verify your generated
>>>>> class files.
>>>>>
>>>>> In addition, CodeBuilder supports chaining; if we add the size
>>>>> checking in each item of the chain, it will introduce a performance penalty.
>>>>>
>>>>> Chen
>>>>>
>>>>> On Sat, Mar 9, 2024 at 8:42 AM Øystein Myhre Andersen <
>>>>> o.myhre at gmail.com> wrote:
>>>>>
>>>>>> Checking for 'Stack size mismatch' is currently done in 'java.base/jdk.internal.classfile.impl.StackMapGenerator'.
>>>>>> It would have been nice if this was tested earlier by Codebuilder when the instructions was created.
>>>>>>
>>>>>> For example, by keeping track of the stack size curing code building.
>>>>>>
>>>>>> It is good programming practice to catch errors as early as possible.
>>>>>>
>>>>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/classfile-api-dev/attachments/20240310/518066c8/attachment.htm>


More information about the classfile-api-dev mailing list