5 ms·

Project Valhalla, Simple as it can be, but not simpler

97 points by pmg1991 3y ago

melenaboija 3y ago
A little bit off topic but this is another challenging Project Valhalla: https://www.youtube.com/watch?v=XL2zzFaybdE&ab_channel=EduMar%C3%ADn https://www.youtube.com/watch?v=XL2zzFaybdE&ab_channel=EduMa...
nyanpasu64 3y ago
Well 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).
canvascritic 3y ago
The 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.
lbj 3y ago
[flagged]
- eklavya 3y ago
  In 2023, do you have reader mode?
  - happymellon 3y ago
    In 2023 I do, but it's still just a work around for people who can't make webpages. As such as can still complain about it.
  - smallnix 3y ago
    No. It does not trigger in Chrome. After 5 min of messing with chrome experimental flags I gave up and kept zooming in and out.
  - samus 3y ago
    It's awful not only on mobile. Even on the desktop it does not take advantage of screen estate. On a 27" 1440p screen, I have to zoom.
- sgt 3y ago
  How does one zoom in Vivaldi. Wouldn't that also be something similar to Cmd-Plus or Cmd-Minus (or Ctrl)?
quelltext 3y ago
From 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.
- PhilipRoman 3y ago
  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.
- DarkNova6 3y ago
  This was not so much a „change in direction“ but rather having a guiding model which assumes the worst case. But by now enough evidence has emerged that the same performance can be achieved with object descriptors. Discussion on the mailing list: https://mail.openjdk.org/pipermail/valhalla-spec-experts/2023-June/002330.html https://mail.openjdk.org/pipermail/valhalla-spec-experts/202...
akkad33 3y ago
I 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?
- whizzter 3y ago
  Value types was in the CLR(_Common_ Language Runtime) from day one as the runtime supported (variations of) C/C++,etc. Iirc proper generics didn't appear in version 1 of C# but since the foundation was there generics could become an addon in terms of new collection classes that could be properly parametrized. Java generics took a shortcut by reusing the old classes and just layering them on in the language but erasing all useful information to the runtime, and this is what's biting them in the back now when practice has shown that flat memory layouts is highly beneficial in terms of performance as CPU speeds has outstripped memory latencies. A List<int> in C# will be 2 objects, the List object and the underlying int[] array of sequential numbers, a Java List<int> will be 2+N objects, the List object, the object[] array and N boxed int objects, and the if N int objects are scattered in memory then traversing the integers will be far more expensive due to memory latencies.
  - pjmlp 3y ago
    Generics were also already on an experimental branch by the time .NET 1.0 was released. Microsoft decided not to delay the release waiting for them to get ready. Don Syme of F# fame has a couple of blog posts with the history of generics in .NET, as he was part of the original design team.
  - kaba0 3y ago
    Regarding List<int> and specializing it to an int[] has more to do with generics than value types. The most important semantic info about a value type is not having identity, that is modifying it is not observable from another thread that were holding the same value previously. This alone lets one do things like freely copy/share/modify them, that directly allows for flattening.
    - 3y ago
smallnix 3y ago
I 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.

97 points by pmg1991 3y ago

A little bit off topic but this is another challenging Project Valhalla: https://www.youtube.com/watch?v=XL2zzFaybdE&ab_channel=EduMar%C3%ADn https://www.youtube.com/watch?v=XL2zzFaybdE&ab_channel=EduMa...

nyanpasu64 3y ago

Well 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).

canvascritic 3y ago

The 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.

lbj 3y ago

[flagged]

eklavya 3y ago
In 2023, do you have reader mode?
- happymellon 3y ago
  In 2023 I do, but it's still just a work around for people who can't make webpages. As such as can still complain about it.
- smallnix 3y ago
  No. It does not trigger in Chrome. After 5 min of messing with chrome experimental flags I gave up and kept zooming in and out.
- samus 3y ago
  It's awful not only on mobile. Even on the desktop it does not take advantage of screen estate. On a 27" 1440p screen, I have to zoom.
sgt 3y ago
How does one zoom in Vivaldi. Wouldn't that also be something similar to Cmd-Plus or Cmd-Minus (or Ctrl)?

quelltext 3y ago

From 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.

PhilipRoman 3y ago
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.
DarkNova6 3y ago
This was not so much a „change in direction“ but rather having a guiding model which assumes the worst case. But by now enough evidence has emerged that the same performance can be achieved with object descriptors. Discussion on the mailing list: https://mail.openjdk.org/pipermail/valhalla-spec-experts/2023-June/002330.html https://mail.openjdk.org/pipermail/valhalla-spec-experts/202...

akkad33 3y ago

I 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?

whizzter 3y ago
Value types was in the CLR(_Common_ Language Runtime) from day one as the runtime supported (variations of) C/C++,etc. Iirc proper generics didn't appear in version 1 of C# but since the foundation was there generics could become an addon in terms of new collection classes that could be properly parametrized. Java generics took a shortcut by reusing the old classes and just layering them on in the language but erasing all useful information to the runtime, and this is what's biting them in the back now when practice has shown that flat memory layouts is highly beneficial in terms of performance as CPU speeds has outstripped memory latencies. A List<int> in C# will be 2 objects, the List object and the underlying int[] array of sequential numbers, a Java List<int> will be 2+N objects, the List object, the object[] array and N boxed int objects, and the if N int objects are scattered in memory then traversing the integers will be far more expensive due to memory latencies.
- pjmlp 3y ago
  Generics were also already on an experimental branch by the time .NET 1.0 was released. Microsoft decided not to delay the release waiting for them to get ready. Don Syme of F# fame has a couple of blog posts with the history of generics in .NET, as he was part of the original design team.
- kaba0 3y ago
  Regarding List<int> and specializing it to an int[] has more to do with generics than value types. The most important semantic info about a value type is not having identity, that is modifying it is not observable from another thread that were holding the same value previously. This alone lets one do things like freely copy/share/modify them, that directly allows for flattening.
  - 3y ago

smallnix 3y ago

I 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.