A lot of people keep talking about Loom and virtual threads, I personally find Project Valhalla more interesting, yet I fully agree that the mix of Loom, Valhalla, Amber, Leyden and Panama, is going to be a game changer for the Java ecosystem. Thanks for all of this!
As always, great content, great video! After watching, I have two questions: 1) Could you make a tutorial (or provide a link to some articles/videos) on how to measure performance, as you do? 2) Why should we not use instance initializers in our code? Is it a performance hit or something else? Thanks in advance.
If I got correctly, value classes are inlined in case of usage if C2 compiler if they are passed as an arguments. It means that we have got overhead of copying of data . So likely this optimisation will depend on size threshold. What about passing the stack pointer then with ability to convert value object into heap object if passed reference leaks the called method ? Are such optimizations considered ?
I downloaded early access builds of Project Valhalla but can not use primitive classes or value classes. Did i something wrong or there are some configuration for using that classes.
I mean ... c# was released 5 years after Java and they pretty much copied all the good parts of Java and had the privilege of knowing what would be problematic or not. They've also broken backwards compatibility multiple times so if they didn't have value types, that would have been really bad
Thanks for a good and comprehensive video. I have a question about the behavior of generic classes: Is there a way to mark that a generic parameter is considered a value type?
Great job José, Question: At 8:08, Why use a primitive keyword on the record type? Couldn't the compiler infer the Product's primitive attribute types as ints?
The main point of primitives is that they can't be null as you're not using references anymore. So even if a record only contains primitives, the compiler can't set the record automatically to primitive itself, as that would cause a huge behaviour change. For example an empty array of that record type would no longer contain nulls.
What is the use of "value abstract class" if you can't declare fields? Aren't they effectively less useful interfaces!? What reason lies to the no field inheritance rule? I know it has to do something with the object memory layout but I don't get the reason for the restriction.
After you loaded the first value from the array A, the rest of that array (or at least a part of it) goes to the CPU cache. Now if you switch to another array B, you basically will discard all that CPU cached data from the array A in order to load data from array B. So basically CPU tries to help you with performance by loading the next portion of the array that you currently reading. But as soon as CPU loads data in cache, you're just switching to another array. Now CPU needs to load data from another array to the cache. And so on. So performance is awful. This is basically the case when you do non-linear reads from the RAM. Which is always will come with hit to the performance. In order to avoid that, the most simple solution, is to make sure your program is always reading data from memory in linear and predictable way. For example, reading all data from the one array first (just doing subsequent reads from the one portion of the memory) and then switch to reading all data from another array (which is in another region of memory). You can learn about it from the this cppcon talk: ruclips.net/video/BP6NxVxDQIs/видео.html - it talks about memory access patterns and how they're important for performance.
And please don't believe me or anyone. Always trust information that you can verify. So I will recommend you to take code examples from that video (or from the talk I sent to you) and run a profiler and try to explain to yourself why it performs in a different way. There are a lot of surprises that you can find. P.S. CPU in reality doesn't have notion of arrays. It just loads in cache whatever is nearby in memory. Or tries to predict your read pattern and loads the "next data". That "next data" will not always be what you expected. But in the most cases, it is just whatever is nearby in memory towards direction of your reads.
And keep in mind that any other READ operation from any other thread or the process on the same CPU core might affect which is currently in the CPU cache. For example, In Java there is Garbage Collector running in the background which can just stop execution of your program at any given time and "pollute" the CPU cache with its data.
Jose, do you think that for graphics and game development purposes vecmath classess such as Vec2 Vec3 Mat4 etc should be defined as value classes or primitive classes?
Question, what about the record class, for example? Will it allow both value and identity? It'll make sense for it to be value only. What about backwards compatibility tho?
primitive classes in this case, I don't think so about value classes also, if you put primitive types (even the primitive primitives like boolean, int) in a class field, you are always allocating
Why doesn't valhalla provide a mutable equivalent to primitive classes? I can understand why value classes are immutable, but I can see many cases where mutable non-reference/primitive classes could be useful. And it wouldn't cause the same problems as mutable value classes because there is only one reference to that object at any time because they're always implicitly copied
value object(value record) get better performance than reference objects(identity record) 1. value objects are non modifiable 2. can't use synchronization
I would like more btw if you do not pause/skip the java sip :) it is strange that you are almost going to drink the coffee then a little blink and you return the cup :+)) don't know :) maybe me personally will like to still have the same music but not the video gap :)
I don't really like this at first glance. Performance is cool, but the constraints on class construction and inheritance feel like an inconsistency in the language. Plus, I feel that between Records and Primitive classes the Value classes don't really feel necessary. If I can have primitive classes and records, what is the big benefit of value classes between the two? Records give up mutability and enforce a canonical constructor for language elegance, pattern matching, etc. Primitive classes will give up mutability and identity for a high performance, dense memory layout and probably put constraints on inheritance, like value classes do. That feels like it leaves value objects as some in-between solution that does a bit of everything, but nothing properly, is hardly needed, but makes the language more cluttered with unimportant things one needs to learn in order to understand it properly.
I think they should have just added a C-style struct to Java and called it there. The complex constraints really limit the applicability of these new language features, when so many people are familiar with the classic struct format.
@@andrewlalis C-style structs come with their own challenges. See what C# for example how they have structs, ref structs, readonly structs, etc. which also give you different behaviors not dissimilar from value and primitive classes.
My understanding is they have both primitive and value classes primarily for two reasons: tearing and default values. Value objects let you use null, primitive objects don't. Not every object is going to have a "sensible" default. 0 kinda makes sense for integers. But what about a Date? What is a "sensible" default? January 1st, 1970? Primitive objects also will re-introduce tearing as a problem. 64 bit values used to be able to "tear": reading and writing wasn't atomic, so a concurrent thread could see partially written primitive types. This isn't a problem on the modern JVM, but it's a tradeoff of performance here, one they weren't willing to make with primitive objects - for performance reasons, they can tear. Value objects won't have this problem, as reading and writing a reference is atomic. As far as just using C-style structs... the design of this seems particularly tailored towards opening up options for optimization. I'm not sure if they could get the same guarantees with C-style structs.
@@bobbycrosby9765 well, I can't comment on tearing, but since records are already immutable (and I expect primitives to be too), should that not eliminate tearing in the first place? And as for defaults, we have the "Optional" monad for that. It might not be perfect for parameters, but it's a better concept than null references and method overloading can avoid some of the ugly regarding optional parameters.
@@brixomatic that only works if you write your whole program as immutable. A plain old object with a primitive field will be subject to tearing - e.g. when you assign that field to a new value. Note that each primitive type will also have a value type automatically created for you. For value objects, part of the concern may have also been backwards compatibility. My understanding is they plan to migrate several existing classes to value objects. Value types are much more backwards compatible than primitive types. I'm also not sure if they're quite so willing to abandon null. Bringing this together a bit, if Optional were changed to a primitive type, then assigning it could be subject to tearing - an identity object in a multi threaded environment could be accessed in a way such that one of its Optional fields wasn't internally consistent.
damn, it is really hard to understand this type of english, can u please provide somebody else? i'm not native speaker to listen this without subtitles
@@brixomatic definitely disagree, intonation is really nasty, even when i'm listen to black people where their english is really too much native with swallowing a lot of words :-) i can understand them much clearly then this speaker. probably you know this accent because you are from the same country. but this english is really bad to hear.
@@romank9482 accents really are something you learn to understand and not every accent is equally hard to understand for everyone, I get that. I have a lot of Indian co-workers and it took years for me to understand some of them properly (you know, the type of calls us where you say "could you send this to me via email, so I won't forget", so you don't have to admit you understood absolutely nothing?) This accent here is a piece of cake in comparison. And also some Brits are near impossible for me to understand. Yes he's flowing some words together and his intonation is very soft, and sometimes he pronounces the last syllable instead of the first one, but that's something that you can get used to very quickly, once you understand the pattern, because that's pretty consistent.
![ROSÉ (로제) - number one girl [더 시즌즈-이영지의 레인보우] | KBS 241129 방송](http://i.ytimg.com/vi/A9oByH9Ci24/mqdefault.jpg)
A lot of people keep talking about Loom and virtual threads, I personally find Project Valhalla more interesting, yet I fully agree that the mix of Loom, Valhalla, Amber, Leyden and Panama, is going to be a game changer for the Java ecosystem. Thanks for all of this!
Also going to make Java a whole lot complex.But I suppose, Java was never meant for the faint hearted!
Merci José. Great job!
Music settings are perfect and better than previous.👌
Better? Maybe. Perfect? Hell no.
Thanks Khaled!
Can't wait for the second part on primitive classes!
Value Objects are exciting!!!
Thanks so much for sharing such a valuable update.After project Loom, Valhalla will make java more faster
As always - very useful and nicely presented. Thanks
Contenu très utile !
Merci beaucoup José !
Je constate que les concepteurs des certifications OCP auront de la matière pour les prochains examens 🙂
Excellent as always. I think I'll have a play around with Valhalla. Looks interesting :)
Great video, thanks for the effort, Valhalla looks like very interesting, I need to learn first Java 17 xD
You should!
PS: Thanks!
Finally Java could get close to C#.
I didn't know C# had value objects.
Cool, I will finally be able to write readable code in LeetCode :P
As always, great content, great video! After watching, I have two questions:
1) Could you make a tutorial (or provide a link to some articles/videos) on how to measure performance, as you do?
2) Why should we not use instance initializers in our code? Is it a performance hit or something else?
Thanks in advance.
The ultimate Java evolution.
WTF.
Thanks for the video. Really helpful
Very important question: where can I find that Java coffee cup? I'd love it but can't seem to find it.
is the benchmarking code available anywhere?
Great video and explanation! Keep up the good work and give us some more :D
Interesting!💚💙💜🤍❤🧡
Thanks Jose sir.
I didn’t quite get one point. With current restrictions on value abstract classes, how do they differ from value interfaces with default methods?
static non-final fields? idk
Maybe multiple inheritance. You can implement many interfaces at same time
At 14:45 identity is mispelled as "identiy"
If I got correctly, value classes are inlined in case of usage if C2 compiler if they are passed as an arguments. It means that we have got overhead of copying of data . So likely this optimisation will depend on size threshold. What about passing the stack pointer then with ability to convert value object into heap object if passed reference leaks the called method ? Are such optimizations considered ?
I downloaded early access builds of Project Valhalla but can not use primitive classes or value classes. Did i something wrong or there are some configuration for using that classes.
Great video!
Yeah, great stuff. On the other hand C# has had value types since the very beginning.
I mean ... c# was released 5 years after Java and they pretty much copied all the good parts of Java and had the privilege of knowing what would be problematic or not. They've also broken backwards compatibility multiple times so if they didn't have value types, that would have been really bad
Thanks for a good and comprehensive video. I have a question about the behavior of generic classes: Is there a way to mark that a generic parameter is considered a value type?
Good idea, I haven't try it. I guess that declaring a value based interface and then T extends ValueInterface would work?
Great job José,
Question: At 8:08, Why use a primitive keyword on the record type? Couldn't the compiler infer the Product's primitive attribute types as ints?
The main point of primitives is that they can't be null as you're not using references anymore. So even if a record only contains primitives, the compiler can't set the record automatically to primitive itself, as that would cause a huge behaviour change. For example an empty array of that record type would no longer contain nulls.
You can. The compiler doesn't do this inference.
What is the use of "value abstract class" if you can't declare fields? Aren't they effectively less useful interfaces!? What reason lies to the no field inheritance rule? I know it has to do something with the object memory layout but I don't get the reason for the restriction.
An abstract class can have static members as well as protected methods.
Jose, why not use records as value objects? If value objects and records are inmutables.
I recall certain abstract classes and interfaces being neither identity or value unless explicitly specified; is this still the case?
14:53
if java could be a human it would be this guy
thanks a lot!
can someone pleaes explain why the two loops approach is faster than the one loop way?
It has to do with pointer chasing. The loops version keeps switching from one array to the other, which is an overhead.
Makes a lot of sense! Thanks for the explaination
After you loaded the first value from the array A, the rest of that array (or at least a part of it) goes to the CPU cache. Now if you switch to another array B, you basically will discard all that CPU cached data from the array A in order to load data from array B.
So basically CPU tries to help you with performance by loading the next portion of the array that you currently reading. But as soon as CPU loads data in cache, you're just switching to another array. Now CPU needs to load data from another array to the cache. And so on. So performance is awful.
This is basically the case when you do non-linear reads from the RAM. Which is always will come with hit to the performance. In order to avoid that, the most simple solution, is to make sure your program is always reading data from memory in linear and predictable way. For example, reading all data from the one array first (just doing subsequent reads from the one portion of the memory) and then switch to reading all data from another array (which is in another region of memory).
You can learn about it from the this cppcon talk: ruclips.net/video/BP6NxVxDQIs/видео.html - it talks about memory access patterns and how they're important for performance.
And please don't believe me or anyone. Always trust information that you can verify. So I will recommend you to take code examples from that video (or from the talk I sent to you) and run a profiler and try to explain to yourself why it performs in a different way. There are a lot of surprises that you can find.
P.S. CPU in reality doesn't have notion of arrays. It just loads in cache whatever is nearby in memory. Or tries to predict your read pattern and loads the "next data". That "next data" will not always be what you expected. But in the most cases, it is just whatever is nearby in memory towards direction of your reads.
And keep in mind that any other READ operation from any other thread or the process on the same CPU core might affect which is currently in the CPU cache. For example, In Java there is Garbage Collector running in the background which can just stop execution of your program at any given time and "pollute" the CPU cache with its data.
Are these benchmarks for "value record" or "primitive record" classes?
He said primitives will be discussed next time.
This discussion was about value record
@@bororobo3805 Indeed it was said. Though I when I run the very same demonstrated benchmarks I get very different numbers, hence the question.
Hello,
What if I do Arrays.sum() for both arrays and then do division so any change will be seen as I am using jdks in built functions
Thank you
Jose, do you think that for graphics and game development purposes vecmath classess such as Vec2 Vec3 Mat4 etc should be defined as value classes or primitive classes?
Well, given the stated performance features, I think it'd be better to have them as primitives.
What's that error number in the benchmarks?
Probably "standard error", a statistical metric. This has nothing to do with logical errors.
Yes. That's exactly that. More details -> openjdk.org/projects/code-tools/jmh/
Thank you for these content
How de you test it ? And do you use for test ?
Tests and benches are done using JMH. More details -> openjdk.org/projects/code-tools/jmh/
what's wrong with instance initilizers?
Question, what about the record class, for example? Will it allow both value and identity?
It'll make sense for it to be value only. What about backwards compatibility tho?
Record is not a value based class as of now, in this EA release. Maybe in the future?
Thanks a lot for this presentation. Does it means that the value objects will live in the Stack instead of the Heap?
They can. This is for the JVM and optimizers to decide. For primitive types, they could live on the heap and in registers.
I always wondered if a *primitive value record can have String fields*? Doesn't matter if there would be a new primitive String class.
The problem is that String wraps an array that is not limited in size. So it would become impossible to inline if it's too big.
@@JosePaumard I'm a bit confused. Why does it prevent inlining since String itself is a reference, and would take up a one word field in the record?
Is this just allocating on the stack, which is a feature that Java should've had from the beginning?
primitive classes in this case, I don't think so about value classes
also, if you put primitive types (even the primitive primitives like boolean, int) in a class field, you are always allocating
Why doesn't valhalla provide a mutable equivalent to primitive classes? I can understand why value classes are immutable, but I can see many cases where mutable non-reference/primitive classes could be useful. And it wouldn't cause the same problems as mutable value classes because there is only one reference to that object at any time because they're always implicitly copied
value object(value record) get better performance than reference objects(identity record)
1. value objects are non modifiable
2. can't use synchronization
I would like more btw if you do not pause/skip the java sip :) it is strange that you are almost going to drink the coffee then a little blink and you return the cup :+)) don't know :) maybe me personally will like to still have the same music but not the video gap :)
I laughed when he said never to use instance initializers, I didn't think they were that bad
The new "value" keyword might break a lot of codes, I hope it ends up like var reserved keyword
I think I've found José's cafe.
ruclips.net/video/MYPVQccHhAQ/видео.html
so, is record not value class? Should we say "value record" ?? 😢
Thanks.
But I would leave that cup down, and stop drinking coffee between breaks (or cut it from video)..
and if you don't know what is an instance initializer, thats perfect. Never use that any way.
🤣🤣🤣🤣🤣🤣🤣
I don't really like this at first glance.
Performance is cool, but the constraints on class construction and inheritance feel like an inconsistency in the language.
Plus, I feel that between Records and Primitive classes the Value classes don't really feel necessary.
If I can have primitive classes and records, what is the big benefit of value classes between the two? Records give up mutability and enforce a canonical constructor for language elegance, pattern matching, etc. Primitive classes will give up mutability and identity for a high performance, dense memory layout and probably put constraints on inheritance, like value classes do. That feels like it leaves value objects as some in-between solution that does a bit of everything, but nothing properly, is hardly needed, but makes the language more cluttered with unimportant things one needs to learn in order to understand it properly.
I think they should have just added a C-style struct to Java and called it there. The complex constraints really limit the applicability of these new language features, when so many people are familiar with the classic struct format.
@@andrewlalis C-style structs come with their own challenges. See what C# for example how they have structs, ref structs, readonly structs, etc. which also give you different behaviors not dissimilar from value and primitive classes.
My understanding is they have both primitive and value classes primarily for two reasons: tearing and default values.
Value objects let you use null, primitive objects don't. Not every object is going to have a "sensible" default. 0 kinda makes sense for integers. But what about a Date? What is a "sensible" default? January 1st, 1970?
Primitive objects also will re-introduce tearing as a problem. 64 bit values used to be able to "tear": reading and writing wasn't atomic, so a concurrent thread could see partially written primitive types. This isn't a problem on the modern JVM, but it's a tradeoff of performance here, one they weren't willing to make with primitive objects - for performance reasons, they can tear. Value objects won't have this problem, as reading and writing a reference is atomic.
As far as just using C-style structs... the design of this seems particularly tailored towards opening up options for optimization. I'm not sure if they could get the same guarantees with C-style structs.
@@bobbycrosby9765 well, I can't comment on tearing, but since records are already immutable (and I expect primitives to be too), should that not eliminate tearing in the first place?
And as for defaults, we have the "Optional" monad for that. It might not be perfect for parameters, but it's a better concept than null references and method overloading can avoid some of the ugly regarding optional parameters.
@@brixomatic that only works if you write your whole program as immutable. A plain old object with a primitive field will be subject to tearing - e.g. when you assign that field to a new value.
Note that each primitive type will also have a value type automatically created for you.
For value objects, part of the concern may have also been backwards compatibility. My understanding is they plan to migrate several existing classes to value objects. Value types are much more backwards compatible than primitive types.
I'm also not sure if they're quite so willing to abandon null.
Bringing this together a bit, if Optional were changed to a primitive type, then assigning it could be subject to tearing - an identity object in a multi threaded environment could be accessed in a way such that one of its Optional fields wasn't internally consistent.
damn, it is really hard to understand this type of english, can u please provide somebody else? i'm not native speaker to listen this without subtitles
I am also not a native speaker and my English is not very good.
But his English is perfect and easy to understand.
I am not a native english speaker. I can understand just fine. His english is too good!
Not a native speaker here, but I think his English is comprehensible enough. You just need to get a bit used to it.
@@brixomatic definitely disagree, intonation is really nasty, even when i'm listen to black people where their english is really too much native with swallowing a lot of words :-) i can understand them much clearly then this speaker. probably you know this accent because you are from the same country. but this english is really bad to hear.
@@romank9482 accents really are something you learn to understand and not every accent is equally hard to understand for everyone, I get that. I have a lot of Indian co-workers and it took years for me to understand some of them properly (you know, the type of calls us where you say "could you send this to me via email, so I won't forget", so you don't have to admit you understood absolutely nothing?) This accent here is a piece of cake in comparison. And also some Brits are near impossible for me to understand. Yes he's flowing some words together and his intonation is very soft, and sometimes he pronounces the last syllable instead of the first one, but that's something that you can get used to very quickly, once you understand the pattern, because that's pretty consistent.