----- Original Message ----- > From: "Jochen Theodorou" <blackd...@gmx.org> > To: "dev" <dev@groovy.apache.org> > Sent: Sunday, January 28, 2024 10:38:24 PM > Subject: Re: [EXT] Re: ClassFile API
> On 28.01.24 15:05, Remi Forax wrote: > [...] >> Hello, >> before i answer to your questions, >> my remark about sealed types is that the API of the classfile library is >> based >> on sealed types and pattern matching. >> A sealed type is not extensible meaning that if you target a specific >> version of >> the classfile API, >> you have to manage the fact that a new subtype of a hierarchy can appear in >> the >> next version. > > yeah, sorry for confusing you and the limited creativity. I did > understand that.. Maybe I should have taken something else as example > that changes the class level, or members. records would have given a > better example > > [..] >>>> It's not only new bytecode, by example with the value type of Valhalla, >>>> you need >>>> to generate the attribute Preload to inform the VM that the class of a >>>> value >>>> type has to be loaded before the value types appears in signature of >>>> methods >>>> and fields. If you fail to do that, it will work, value classes are >>>> backward >>>> compatible with identity (classical) classes but you will not get any >>>> optimization so any benchmarks of Groovy vs Java will be unfair. >>> >>> How does Java do that? >> >> Here is the current VM spec >> https://cr.openjdk.org/~dlsmith/jep401/jep401-20240116/specs/value-objects-jvms.html > > oh wow... the decision with the class file version 67.65535 is a bit > strong... is it then 68.65535 in Java24? If they wanted to introduce > class file variants they could have made that differently - or not? 68 as major version is Java 24, 65525 as minor version means preview. The current plan is to introduce value classes as a preview feature. > >> Here is the current JEP >> https://openjdk.java.net/jeps/401 >> >> If a class V is declared as a value class, and a class A uses the class V, >> the >> class A should contain a new attribute Preload that lists "V" as a class to >> preload. >> Preloading the class allows the VM to see that a class is not a normal class >> but >> a value class (if you ask for preloading a normal class, the VM will do >> nothing >> more). >> When the VM knows that a class is a value class, internally the way to pass >> parameters is changed (the values of the fields are sent instead of a >> pointer) >> and on stack/in registers the values of the field are used instead of a >> pointer. So at runtime, it's like if they were no boxing. > > I assume this means no change for using invokedynamic. The > implementation would have to change of course... well at least if that > is to be used there as well. yes, no change for invokedynamic from the user POV. In fact, given that invokedynamic is only linked at runtime, we know that at call site no boxing will occur. But, boxing may occur if the target method has already been loaded without the values classes of its descriptor being preloaded at the time the target method was created. > >> This is true for user defined value class but also some classes of the JDK >> like >> Integer, Boolean, etc or Optional that are retrofitted to be value class. > > So if I have a method that takes a Number as parameter there will be no > value type handling? yes, and no. If the method is too big to be inlined, the value will be boxed. If the method is inlined, there will be no boxing. > > bye Jochen regards, Rémi
