From o.myhre at gmail.com Tue Jul 16 10:30:38 2024 From: o.myhre at gmail.com (=?UTF-8?Q?=C3=98ystein_Myhre_Andersen?=) Date: Tue, 16 Jul 2024 12:30:38 +0200 Subject: Exception: Unexpected label context Message-ID: I got: Exception in thread "main" java.lang.IllegalStateException: Unexpected label context CodeBuilder[id=1816757085] in =CodeBuilder[id=1730173572] at ... DirectCodeBuilder.labelToBci(DirectCodeBuilder.java:702) at ... DirectCodeBuilder.writeLabelOffset(DirectCodeBuilder.java:465) at ... DirectCodeBuilder.writeTableSwitch(DirectCodeBuilder.java:577) I did some tests and found that bci had become greater than the max short value. I guessed the Method was too big. Then I split it up. That solved the problem ! Perhaps 'labelToBci' should check if bci became too large and in that case give an error: "Method too large" - ?ystein Myhre Andersen -------------- next part -------------- An HTML attachment was scrubbed... URL: From chen.l.liang at oracle.com Thu Jul 18 19:18:23 2024 From: chen.l.liang at oracle.com (Chen Liang) Date: Thu, 18 Jul 2024 19:18:23 +0000 Subject: Exception: Unexpected label context In-Reply-To: References: Message-ID: Hi Oystein, Can you provide a minimal reproduction case for this problem? The stacktrace you've provided looks eerily similar to another one where CodeTransform reads labels it doesn't know because our transform chaining was not propagating the Labels correctly. (Fixed in 23 and 24 very recently) - Chen ________________________________ From: classfile-api-dev on behalf of ?ystein Myhre Andersen Sent: Tuesday, July 16, 2024 5:30 AM To: classfile-api-dev Subject: Exception: Unexpected label context I got: Exception in thread "main" java.lang.IllegalStateException: Unexpected label context CodeBuilder[id=1816757085] in =CodeBuilder[id=1730173572] at ... DirectCodeBuilder.labelToBci(DirectCodeBuilder.java:702) at ... DirectCodeBuilder.writeLabelOffset(DirectCodeBuilder.java:465) at ... DirectCodeBuilder.writeTableSwitch(DirectCodeBuilder.java:577) I did some tests and found that bci had become greater than the max short value. I guessed the Method was too big. Then I split it up. That solved the problem ! Perhaps 'labelToBci' should check if bci became too large and in that case give an error: "Method too large" - ?ystein Myhre Andersen -------------- next part -------------- An HTML attachment was scrubbed... URL: From o.myhre at gmail.com Fri Jul 26 09:35:36 2024 From: o.myhre at gmail.com (=?UTF-8?Q?=C3=98ystein_Myhre_Andersen?=) Date: Fri, 26 Jul 2024 11:35:36 +0200 Subject: Multiple method build in classBuilder Message-ID: The attached code contains the building of a class with one method '_STM'. When the method gets too big, more than 32,767 bytes, a weird situation occurs. Look at lines 93-94: Here the size of the code can be changed. When the code is greater than 32,767 (caseBlockSize = 13000) the Method 'buildMethod_STM' is called twice with different CodeBuilders !!! When caseBlockSize = 10000 everything is OK. There must be something wrong here. - ?ystein Myhre Andersen -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Testing.java Type: application/octet-stream Size: 3364 bytes Desc: not available URL: From maurizio.cimadamore at oracle.com Fri Jul 26 15:17:08 2024 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Fri, 26 Jul 2024 16:17:08 +0100 Subject: Multiple method build in classBuilder In-Reply-To: References: Message-ID: I think this is as expected? E.g. by default the classfile API will consider all jumps to be "short jumps" (e.g. "goto" instead of "goto_w"). If that fails (e.g. because the code is too big), code generation is "replayed", this time using "long jumps" (e.g. "goto_w" instead of "goto"). This is why you see the consumer being called twice. Maurizio On 26/07/2024 10:35, ?ystein Myhre Andersen wrote: > The attached code contains the building of a class with one method '_STM'. > When the method gets too big, more than 32,767?bytes, a weird > situation occurs. > > Look at lines 93-94: Here the size of the code can be changed. > When the code is greater than 32,767? (caseBlockSize = 13000) > the Method 'buildMethod_STM' is called twice with different > CodeBuilders !!! > > When caseBlockSize = 10000 everything is OK. > > There must be something wrong here. > > - ?ystein Myhre Andersen From o.myhre at gmail.com Fri Jul 26 16:32:10 2024 From: o.myhre at gmail.com (=?UTF-8?Q?=C3=98ystein_Myhre_Andersen?=) Date: Fri, 26 Jul 2024 18:32:10 +0200 Subject: Multiple method build in classBuilder In-Reply-To: References: Message-ID: Really, that's how it's supposed to work. Then I learned something new today. Thank you ! On Fri, Jul 26, 2024 at 5:17?PM Maurizio Cimadamore < maurizio.cimadamore at oracle.com> wrote: > I think this is as expected? E.g. by default the classfile API will > consider all jumps to be "short jumps" (e.g. "goto" instead of "goto_w"). > > If that fails (e.g. because the code is too big), code generation is > "replayed", this time using "long jumps" (e.g. "goto_w" instead of "goto"). > > This is why you see the consumer being called twice. > > Maurizio > > On 26/07/2024 10:35, ?ystein Myhre Andersen wrote: > > The attached code contains the building of a class with one method > '_STM'. > > When the method gets too big, more than 32,767 bytes, a weird > > situation occurs. > > > > Look at lines 93-94: Here the size of the code can be changed. > > When the code is greater than 32,767 (caseBlockSize = 13000) > > the Method 'buildMethod_STM' is called twice with different > > CodeBuilders !!! > > > > When caseBlockSize = 10000 everything is OK. > > > > There must be something wrong here. > > > > - ?ystein Myhre Andersen > -------------- next part -------------- An HTML attachment was scrubbed... URL: From maurizio.cimadamore at oracle.com Fri Jul 26 16:44:22 2024 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Fri, 26 Jul 2024 17:44:22 +0100 Subject: Multiple method build in classBuilder In-Reply-To: References: Message-ID: <00019a19-91fe-4d98-9566-144c2d43334a@oracle.com> Heh. Note that this is also mentioned (in better words than mine) in the dlassfile API JEP [1]: > This is more specific and transparent [...]. Yet there is already a > powerful hidden benefit: By capturing the sequence of operations in a > lambda we get the possibility of /replay/, which enables the library > to do work that previously the client had to do. For example, branch > offsets can be either short or long. If clients generate instructions > imperatively then they have to compute the size of each branch's > offset when generating the branch, which is complex and error prone. > But if the client provides a lambda that takes a builder then the > library can optimistically try to generate the method with short > offsets and, if that fails, discard the generated state and re-invoke > the lambda with different code generation parameters. Maurizio [1] - https://openjdk.org/jeps/466 On 26/07/2024 17:32, ?ystein Myhre Andersen wrote: > Really, that's how it's supposed to work. > Then I learned something new today. > > Thank you ! > > On Fri, Jul 26, 2024 at 5:17?PM Maurizio Cimadamore > wrote: > > I think this is as expected? E.g. by default the classfile API will > consider all jumps to be "short jumps" (e.g. "goto" instead of > "goto_w"). > > If that fails (e.g. because the code is too big), code generation is > "replayed", this time using "long jumps" (e.g. "goto_w" instead of > "goto"). > > This is why you see the consumer being called twice. > > Maurizio > > On 26/07/2024 10:35, ?ystein Myhre Andersen wrote: > > The attached code contains the building of a class with one > method '_STM'. > > When the method gets too big, more than 32,767?bytes, a weird > > situation occurs. > > > > Look at lines 93-94: Here the size of the code can be changed. > > When the code is greater than 32,767? (caseBlockSize = 13000) > > the Method 'buildMethod_STM' is called twice with different > > CodeBuilders !!! > > > > When caseBlockSize = 10000 everything is OK. > > > > There must be something wrong here. > > > > - ?ystein Myhre Andersen > -------------- next part -------------- An HTML attachment was scrubbed... URL: