Project Valhalla, Simple as it can be, but not simpler
cr.openjdk.org
Project Valhalla, Simple as it can be, but not simpler
1–10 of 33 posts
Re: Project Valhalla, Simple as it can be, but not simpler
#2Well I suppose that if you treat value types like a variation of an object reference rather than a variation of an object, then it would make sense that they cannot be mutated (since neither can object references but only their targets), with the added wrinkle of allowing such mutation during value constructors. To me this still feels less general than C or Go structs, which can have individual fields mutated in place (and even take the address of stack variables and pass pointers around, though that's unsafe in C and may require heap/GC allocation in Go unless escape analysis proves otherwise).
Re: Project Valhalla, Simple as it can be, but not simpler
#3The shift in valhalla's direction reminds me of the initial challenges i faced when experimenting with its early prototypes. i distinctly remember grappling with the introduction of q-types and v-bytecodes and trying to align it with my existing understanding of the jvm. it's interesting to see how the design is evolving towards expressing struct-like values as normal java classes. from my own tinkering with valhalla, the convergence towards a more streamlined approach without losing out on performance seems promising. curious to see how these changes will play out in real world applications, especially considering the nuances of java's memory model and optimization techniques.
Re: Project Valhalla, Simple as it can be, but not simpler
#4[flagged]
Re: Project Valhalla, Simple as it can be, but not simpler
#5[flagged]
In 2023, do you have reader mode?
Re: Project Valhalla, Simple as it can be, but not simpler
#6Re: Project Valhalla, Simple as it can be, but not simpler
#7From the start I was wondering if there's no way for the JVM to solve this with less cruft on the bytecode level. Of course, that doesn't mean I was aware of the challenges, just an intuition.
I do think they must have had similar intuitions in the beginning. Then identified big challenges with that and that what would be needed to overcome it more streamlined is some set of features or optimizations. It seems though that these emerged in isolation? At least to cross the threshold to saying "there's a way".
Seeing how long Valhalla has been in development, I'm curious how things went the way they did. The article mentions hindsight but that alone doesn't explain the change in direction.
Re: Project Valhalla, Simple as it can be, but not simpler
#8From the start I was wondering if there's no way for the JVM to solve this with less cruft on the bytecode level. Of course, that doesn't mean I was aware of the challenges, just an intuition. I do think they must have had similar intuitions in the beginning. Then identified big challenges with that and that what would be needed to overcome it more streamlined is some set of features or optimizations. It seems though…
There is always the cheap way out - generate garbage bytecode and leave it to the hotspot team to clean up the mess with intrinsics. Sort of like the vector API is implemented with objects, but obviously no one wants allocations in the middle of tight vector loops, so HotSpot just treats them as a special case.
Re: Project Valhalla, Simple as it can be, but not simpler
#9I haven't read the article fully, but can anyone please explain why value types seem so much more complicated in the JVM than DotNet, where they have had it for a long time?
Re: Project Valhalla, Simple as it can be, but not simpler
#10I understand it's in jest but I don't think Einsteins version "blew it". The simplified (and definitely catchier) aphorism misses to explain what the criterion for enough or not enough is.