From adam.sotona at oracle.com Mon Mar 4 09:20:54 2024 From: adam.sotona at oracle.com (Adam Sotona) Date: Mon, 4 Mar 2024 09:20:54 +0000 Subject: RFR: ClassFile API PRs to review Message-ID: Hi, I would like to ask for review of these two PRS: 8323183: ClassFile API performance improvements #17306 8325485: IncrementInstructions.of(int, int) is not storing the args #17770 Thank you! Adam -------------- next part -------------- An HTML attachment was scrubbed... URL: From o.myhre at gmail.com Sat Mar 9 12:35:57 2024 From: o.myhre at gmail.com (=?UTF-8?Q?=C3=98ystein_Myhre_Andersen?=) Date: Sat, 9 Mar 2024 13:35:57 +0100 Subject: Checking for 'Stack size mismatch' Message-ID: 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: From o.myhre at gmail.com Sat Mar 9 15:25:04 2024 From: o.myhre at gmail.com (=?UTF-8?Q?=C3=98ystein_Myhre_Andersen?=) Date: Sat, 9 Mar 2024 16:25:04 +0100 Subject: New pseudo instruction CodeBuilder.setDebugOption Message-ID: *Proposal:* Add a new pseudo instruction: CodeBuilder.setDebugOption(int kind, int level) Meaning: kind == 1 // CodeListing 2 .. n // Reserved when kind == 1 level == 0 // Off 1 // code listing as when "stack size mismatch" error. 2 // with additional Thread.dumpstack(); 3 .. n // Reserved Or something like it. *Motivation:* I am building a code generator for the Open Source Simula compiler. During debugging, it would be nice to be able to see the code that is generated and possibly where the individual instructions were generated from. This is particularly interesting for errors such as: "stack size mismatch", "operand stack underflow", etc. -------------- next part -------------- An HTML attachment was scrubbed... URL: From liangchenblue at gmail.com Sat Mar 9 18:38:01 2024 From: liangchenblue at gmail.com (-) Date: Sat, 9 Mar 2024 12:38:01 -0600 Subject: Checking for 'Stack size mismatch' In-Reply-To: References: Message-ID: 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 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: From liangchenblue at gmail.com Sat Mar 9 18:42:39 2024 From: liangchenblue at gmail.com (-) Date: Sat, 9 Mar 2024 12:42:39 -0600 Subject: New pseudo instruction CodeBuilder.setDebugOption In-Reply-To: References: Message-ID: Hi ?ystein, I think this debug option in particular is quite limited; it can carry only 2 integers. For the purpose of interleaved debugging instructions, I think maybe expanding pseudo instructions to allow custom pseudo instructions (such as from user-defined attributes) may be more applicable. If you mean general Class-File generation options, we usually keep them in the ClassFile object, stored as one of the ClassFile.Options. Chen On Sat, Mar 9, 2024 at 11:42?AM ?ystein Myhre Andersen wrote: > *Proposal:* > > Add a new pseudo instruction: > CodeBuilder.setDebugOption(int kind, int level) > > Meaning: > kind == 1 // CodeListing > 2 .. n // Reserved > > when kind == 1 > level == 0 // Off > 1 // code listing as when "stack size mismatch" error. > 2 // with additional Thread.dumpstack(); > 3 .. n // Reserved > > Or something like it. > > *Motivation:* > > I am building a code generator for the Open Source Simula > compiler. > > During debugging, it would be nice to be able to see the code that is > generated and possibly where the individual instructions were generated > from. > > This is particularly interesting for errors such as: "stack size > mismatch", "operand stack underflow", etc. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From o.myhre at gmail.com Sat Mar 9 20:03:55 2024 From: o.myhre at gmail.com (=?UTF-8?Q?=C3=98ystein_Myhre_Andersen?=) Date: Sat, 9 Mar 2024 21:03:55 +0100 Subject: Checking for 'Stack size mismatch' In-Reply-To: References: Message-ID: 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 - 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 > 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: From o.myhre at gmail.com Sat Mar 9 20:09:43 2024 From: o.myhre at gmail.com (=?UTF-8?Q?=C3=98ystein_Myhre_Andersen?=) Date: Sat, 9 Mar 2024 21:09:43 +0100 Subject: New pseudo instruction CodeBuilder.setDebugOption In-Reply-To: References: Message-ID: Do you have other ideas. Have you ever written a code generator for a compiler ? I don't think you understood the question On Sat, Mar 9, 2024 at 7:42?PM - wrote: > Hi ?ystein, > I think this debug option in particular is quite limited; it can carry > only 2 integers. For the purpose of interleaved debugging instructions, I > think maybe expanding pseudo instructions to allow custom pseudo > instructions (such as from user-defined attributes) may be more applicable. > > If you mean general Class-File generation options, we usually keep them in > the ClassFile object, stored as one of the ClassFile.Options. > > Chen > > On Sat, Mar 9, 2024 at 11:42?AM ?ystein Myhre Andersen > wrote: > >> *Proposal:* >> >> Add a new pseudo instruction: >> CodeBuilder.setDebugOption(int kind, int level) >> >> Meaning: >> kind == 1 // CodeListing >> 2 .. n // Reserved >> >> when kind == 1 >> level == 0 // Off >> 1 // code listing as when "stack size mismatch" error. >> 2 // with additional Thread.dumpstack(); >> 3 .. n // Reserved >> >> Or something like it. >> >> *Motivation:* >> >> I am building a code generator for the Open Source Simula >> compiler. >> >> During debugging, it would be nice to be able to see the code that is >> generated and possibly where the individual instructions were generated >> from. >> >> This is particularly interesting for errors such as: "stack size >> mismatch", "operand stack underflow", etc. >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From liangchenblue at gmail.com Sat Mar 9 21:10:38 2024 From: liangchenblue at gmail.com (-) Date: Sat, 9 Mar 2024 15:10:38 -0600 Subject: Checking for 'Stack size mismatch' In-Reply-To: References: Message-ID: 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 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 - 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 >> 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: From liangchenblue at gmail.com Sat Mar 9 21:13:15 2024 From: liangchenblue at gmail.com (-) Date: Sat, 9 Mar 2024 15:13:15 -0600 Subject: New pseudo instruction CodeBuilder.setDebugOption In-Reply-To: References: Message-ID: Oh, so you want more debugging info in error messages from CodeBuilder or StackMapGenerator. That usually goes to the overall ClassFile object in our current model. So you want to dump the instructions for the whole code upon code building failure, but dumping stack for each instruction is quite unrealistic. Your better bet would be a debugger. On Sat, Mar 9, 2024 at 2:09?PM ?ystein Myhre Andersen wrote: > Do you have other ideas. Have you ever written a code generator for a > compiler ? > > I don't think you understood the question > > On Sat, Mar 9, 2024 at 7:42?PM - wrote: > >> Hi ?ystein, >> I think this debug option in particular is quite limited; it can carry >> only 2 integers. For the purpose of interleaved debugging instructions, I >> think maybe expanding pseudo instructions to allow custom pseudo >> instructions (such as from user-defined attributes) may be more applicable. >> >> If you mean general Class-File generation options, we usually keep them >> in the ClassFile object, stored as one of the ClassFile.Options. >> >> Chen >> >> On Sat, Mar 9, 2024 at 11:42?AM ?ystein Myhre Andersen >> wrote: >> >>> *Proposal:* >>> >>> Add a new pseudo instruction: >>> CodeBuilder.setDebugOption(int kind, int level) >>> >>> Meaning: >>> kind == 1 // CodeListing >>> 2 .. n // Reserved >>> >>> when kind == 1 >>> level == 0 // Off >>> 1 // code listing as when "stack size mismatch" error. >>> 2 // with additional Thread.dumpstack(); >>> 3 .. n // Reserved >>> >>> Or something like it. >>> >>> *Motivation:* >>> >>> I am building a code generator for the Open Source Simula >>> compiler. >>> >>> During debugging, it would be nice to be able to see the code that is >>> generated and possibly where the individual instructions were generated >>> from. >>> >>> This is particularly interesting for errors such as: "stack size >>> mismatch", "operand stack underflow", etc. >>> >>> -------------- next part -------------- An HTML attachment was scrubbed... URL: From o.myhre at gmail.com Sun Mar 10 14:21:22 2024 From: o.myhre at gmail.com (=?UTF-8?Q?=C3=98ystein_Myhre_Andersen?=) Date: Sun, 10 Mar 2024 15:21:22 +0100 Subject: Checking for 'Stack size mismatch' In-Reply-To: References: Message-ID: 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 - 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 > 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 - 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 >>> 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: From o.myhre at gmail.com Sun Mar 10 14:54:57 2024 From: o.myhre at gmail.com (=?UTF-8?Q?=C3=98ystein_Myhre_Andersen?=) Date: Sun, 10 Mar 2024 15:54:57 +0100 Subject: Checking for 'Stack size mismatch' In-Reply-To: References: Message-ID: 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 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 - 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 >> 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 - 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: From o.myhre at gmail.com Sun Mar 10 15:04:29 2024 From: o.myhre at gmail.com (=?UTF-8?Q?=C3=98ystein_Myhre_Andersen?=) Date: Sun, 10 Mar 2024 16:04:29 +0100 Subject: Checking for 'Stack size mismatch' In-Reply-To: References: Message-ID: 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 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 > 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 - 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 >>> 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 - 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: From david32768 at btinternet.com Sat Mar 16 08:49:25 2024 From: david32768 at btinternet.com (david32768@btinternet.com david32768@btinternet.com) Date: Sat, 16 Mar 2024 08:49:25 +0000 (GMT) Subject: Stack Checker Message-ID: <2cbf549f.1d56.18e46739c9f.Webtop.95@btinternet.com> I have written a stack checker transform from scratch. The following are my observations for this task, # BranchInstruction It would help if BranchInstruction could be divided into BinaryBranchInstruction and UnaryBranchInstruction. Opcodes GOTO and GOTO_W could go in Unary as TypeKind.Void has to dealt with for method return. There is a bug in java.lang.classfile.Opcode: the TypeKind for IFNONNULL should be ReferenceType. #OperatorInstruction It would help if OperationInstruction could be divided into Binary(IADD etc,), Unary(INEG etc.), Shift(LSHR etc,), Compare(LCMP etc) and ARRAYLENGTH. There is a bug in jdk.internal.classfile.impl.CodeStackTrackerImpl: Compare(LCMP etc.) return IntType not LongType etc. as returned by typeKind() Regards David -------------- next part -------------- An HTML attachment was scrubbed... URL: From brian.goetz at oracle.com Sat Mar 16 20:10:02 2024 From: brian.goetz at oracle.com (Brian Goetz) Date: Sat, 16 Mar 2024 16:10:02 -0400 Subject: Stack Checker In-Reply-To: <2cbf549f.1d56.18e46739c9f.Webtop.95@btinternet.com> References: <2cbf549f.1d56.18e46739c9f.Webtop.95@btinternet.com> Message-ID: <5b331c21-cc17-44a6-85ee-9aff0a971177@oracle.com> Thanks for the bug reports. Can you explain a little more about what you would do differently if the opcodes reflected the distinction between unary/binary operators, and similarly unary/binary branch? On 3/16/2024 4:49 AM, david32768 at btinternet.com david32768 at btinternet.com wrote: > > I have written a stack checker transform from scratch. The following > are my observations for this task, > > > # BranchInstruction > > > It would help if BranchInstruction could be divided into > BinaryBranchInstruction and UnaryBranchInstruction. > > > Opcodes GOTO and GOTO_W could go in Unary as TypeKind.Void has to > dealt with for method return. > > > There is a bug in java.lang.classfile.Opcode: the TypeKind for > IFNONNULL should be ReferenceType. > > > #OperatorInstruction > > > It would help if OperationInstruction could be divided into > Binary(IADD etc,), Unary(INEG etc.), Shift(LSHR etc,), Compare(LCMP > etc) and ARRAYLENGTH. > > > There is a bug in jdk.internal.classfile.impl.CodeStackTrackerImpl: > Compare(LCMP etc.) return IntType not LongType etc. as returned by > typeKind() > > > Regards > > David > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From adam.sotona at oracle.com Mon Mar 18 08:22:35 2024 From: adam.sotona at oracle.com (Adam Sotona) Date: Mon, 18 Mar 2024 08:22:35 +0000 Subject: Checking for 'Stack size mismatch' In-Reply-To: References: Message-ID: Hi, You are suggesting very specific operations with significant performance effects to be applied for all ClassFile API use cases. Instead of wiring a specific code inside all the code building I suggest you to look at java.lang.classfile.components.CodeStackTracker for inspiration. This way you can (conditionally) plug any custom transformation into your code building. For example a transformation that would print out a debug output you asked in another thread, or you may track origin of labels, verify actual stack content, print out any additional info, all optional and without affecting the core performance. Adam From: classfile-api-dev on behalf of ?ystein Myhre Andersen Date: Sunday, March 10, 2024 at 16:04 To: liangchenblue at gmail.com Cc: classfile-api-dev at openjdk.org Subject: Re: Checking for 'Stack size mismatch' 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 > 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 > 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 - > 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 > 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 - > 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 > 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: From o.myhre at gmail.com Mon Mar 18 09:22:24 2024 From: o.myhre at gmail.com (=?UTF-8?Q?=C3=98ystein_Myhre_Andersen?=) Date: Mon, 18 Mar 2024 10:22:24 +0100 Subject: Checking for 'Stack size mismatch' In-Reply-To: References: Message-ID: Thanks for the tip! On Mon, Mar 18, 2024 at 9:22?AM Adam Sotona wrote: > Hi, > > You are suggesting very specific operations with significant performance > effects to be applied for all ClassFile API use cases. > > Instead of wiring a specific code inside all the code building I suggest > you to look at java.lang.classfile.components.CodeStackTracker > > for inspiration. > > This way you can (conditionally) plug any custom transformation into your > code building. For example a transformation that would print out a debug > output you asked in another thread, or you may track origin of labels, > verify actual stack content, print out any additional info, all optional > and without affecting the core performance. > > > > Adam > > > > *From: *classfile-api-dev on behalf > of ?ystein Myhre Andersen > *Date: *Sunday, March 10, 2024 at 16:04 > *To: *liangchenblue at gmail.com > *Cc: *classfile-api-dev at openjdk.org > *Subject: *Re: Checking for 'Stack size mismatch' > > 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 > 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 > 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 - 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 > 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 - 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 > 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: From adam.sotona at oracle.com Thu Mar 21 14:42:38 2024 From: adam.sotona at oracle.com (Adam Sotona) Date: Thu, 21 Mar 2024 14:42:38 +0000 Subject: RFR: 8320396: Class-File API ClassModel::verify should include checks from hotspot/share/classfile/classFileParser.cpp In-Reply-To: <0a66asWcJ4_zBrjmReA18BZmsovN1ZeJRRSAPZDMZmo=.5bada03f-d88d-46cd-962d-c1e42c3048c1@github.com> References: <0a66asWcJ4_zBrjmReA18BZmsovN1ZeJRRSAPZDMZmo=.5bada03f-d88d-46cd-962d-c1e42c3048c1@github.com> Message-ID: ClassFile API `jdk.internal.classfile.verifier.VerifierImpl` performed only bytecode-level class verification. This patch adds `jdk.internal.classfile.verifier.ParserVerifier` with additional class checks inspired by `hotspot/share/classfile/classFileParser.cpp`. Also new `VerifierSelfTest::testParserVerifier` has been added. Please review. Thanks, Adam ------------- Commit messages: - work in progress - work in progress - work in progress - work in progress - work in progress - removed string templates from test - work in progress - work in progress - work in progress - work in progress - ... and 15 more: https://git.openjdk.org/jdk/compare/784f11c3...b3c34820 Changes: https://git.openjdk.org/jdk/pull/16809/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=16809&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8320396 Stats: 706 lines in 6 files changed: 672 ins; 8 del; 26 mod Patch: https://git.openjdk.org/jdk/pull/16809.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16809/head:pull/16809 PR: https://git.openjdk.org/jdk/pull/16809 -------------- next part -------------- An HTML attachment was scrubbed... URL: From zjx001202 at gmail.com Sat Mar 30 03:59:39 2024 From: zjx001202 at gmail.com (Glavo) Date: Sat, 30 Mar 2024 11:59:39 +0800 Subject: Class-File for Java 17 has just released a new version Message-ID: Hello everyone, I extracted Classfile API from JDK, ported it back to Java 17, and published it to Maven Central as a standalone library. Here is its repository: https://github.com/Glavo/classfile Just now, I released version 0.5.0, this version is synchronized with mainline (openjdk/jdk at 0156909). Welcome everyone to try it and give feedback. Glavo -------------- next part -------------- An HTML attachment was scrubbed... URL: