5 ms·

(Disclaimer: Vale lead here!) You might be interested in what we're working on with Vale, its core innovations happen to be around memory management. Some off

(Disclaimer: Vale lead here!) You might be interested in what we're working on with Vale, its core innovations happen to be around memory management. Some off the top of my head: * Generational references, for single-ownership memory safety without garbage collection, ref counting, or borrow checking. [0] * Higher RAII, a form of "linear typing" that lets us add parameters and returns to destructors, to enforce that if you do X, you won't forget to do Y. [1] * Regions, which could make it so we can eliminate most generation checks in Vale. If it catches on, it could also help other paradigms and get reference counting back into the fight. (Note, we aren't done with this one yet, it's about 3-8 weeks out) [2] Those are just a few off the top of my head, there are a lot of crazy ideas floating around there. I'm hoping they'll combine to form something like an easier more flexible Rust, because that's the holy grail of language design, to me at least. A few years ago, I was also pretty down about the state of memory innovation... it felt like not much had been discovered since borrow checking. I knew there had to be something with its speed, but the flexibility of C++. Perhaps we found it! [0] https://verdagon.dev/blog/generational-references https://verdagon.dev/blog/generational-references [1] https://verdagon.dev/blog/higher-raii-7drl https://verdagon.dev/blog/higher-raii-7drl [2] https://verdagon.dev/blog/zero-cost-refs-regions https://verdagon.dev/blog/zero-cost-refs-regions

avgcorrection 4y ago
Don’t save the disclaimer for last.
- verdagon 4y ago
  Happy to oblige, edited it upward. Hope your day is going well =)
  - avgcorrection 4y ago
    It is, and thanks!
zozbot234 4y ago
The real disclaimer should perhaps be that this stuff is something that's still being worked on wrt. production use, just like many other kinds of PL research. Once it's ready, Rust will probably be in a very good position to adopt these features.
- verdagon 4y ago
  That would be pretty cool! I'm not sure Rust can support these features, though. * Generational References involve some pretty deep compiler support. One can implement something like it in Rust with a thread-local side table, but with >3x overhead compared to language-supported generational references. * Higher RAII requires that a language not treat destructors and panic handlers as the same thing. Unfortunately, Rust uses one function (drop) for both. Additionally, it would be a backwards-incompatible change; Rust generic parameters already assume a zero-arg drop() is available for all parameters, even though there's no trait bound declared for them. * Regions get most of the borrow checker's optimizing power with a fraction of the user complexity. Having both borrow checking and regions would just be adding complexity though, which defeats the purpose a bit. Still, there are a few other features of Vale that we're thinking of proposing to Rust, especially around concurrency, determinism, and better memory safety guarantees.
tomp 4y ago
I've been following Vale's progress with interest but AFAIK as of a few months ago, it's still vapourware. Excited to learn you're nearing an actual implementation though! Let's hope it's practical!
- verdagon 4y ago
  If talking about regions and HGM, that's fair to say. Regions are further behind where I hoped because the latter stages are blocked on generics, and I had to take 8 months off a year ago because of some PTSD from work (long story). I acknowledge that these are excuses, and that these two features of Vale can reasonably be regarded as vaporware until we get them finished. We're over halfway done with regions, fingers crossed for September! For what it's worth, most of our innovations are actually complete and released. Generational References, Fearless FFI (minus sandboxing), and Higher RAII are all done and usable, and the Perfect Replayability proof-of-concept is finished as well. All these are in version 0.2, which can be downloaded at [0]. And if you ever want to see what we're working on, we have a "What's been happening recently" on the roadmap page [1]. Thanks for following along! [0] https://vale.dev/download https://vale.dev/download [1] https://vale.dev/roadmap https://vale.dev/roadmap
  - chrissinclair 4y ago
    > I acknowledge that these are excuses I'm not privy to the story here, but taking eight months off to treat PTSD doesn't sound like an excuse to me, but a really important period of time that needed to be taken. I hope you're doing alright now, but don't let yourself go thinking that taking time to deal with something like that is an excuse for other things not happening - it's far more important. Separately, I've not checked Vale out yet, but props to you for diving in on new ways of handling memory and RAII - looks really interesting and I'll be giving the language a whirl at some point soon!
    - verdagon 4y ago
      Thanks mate, I appreciate the kind words. I try not to judge myself too harshly for taking the time off, but it does help to hear it from a kind soul such as yourself. Luckily, the PTSD isn't spilling over into my other interests (games, Vale, etc) much any more so life is steadily improving!
whizzter 4y ago
Generational References is quite a neat trick, obvious in hindsight! I assume that the general idea is that non-owners really only have "weak" references (and safety comes from the compiler warning/checking that this isn't broken). One thing though about them is that I assume the generation to be co-located with the memory? If so, then the runtime wouldn't be able to free memory back to the OS while running? (Unless implemented with a side-lookup but that would hamper runtime performance?)
- verdagon 4y ago
  Askin' the right questions! The generations are colocated with the objects, and we can release memory back to the OS using the virtual memory shenanigans explained in [0]. However, the design and implementation have simplified quite a bit since that article. Now: * We use these generations only for assertions on dereferencing non-owning references, and don't use them for weak references anymore. * We let malloc release memory back to the OS like normal. If the user dereferences something in a released page, we'll get a page fault instead of an assertion failure, but both are handled the same. * When the generation hits INT_MAX, we just let it overflow now instead of blacklisting the allocation forever. These adjustments mean we never need the heap which is a big improvement, and really unlocks Vale as a systems programming language. The purposeful overflowing does mean that only 99.99999998% of invalid memory accesses will halt the program, which is more than enough certainty in practice [1]. (The probability is actually higher, as we increment generations by prime numbers and won't even hit our first possible collision until well after most runs have ended.) [0] https://lobste.rs/s/sglvcc/generational_references_2_3x_faster_than#c_gqakeg https://lobste.rs/s/sglvcc/generational_references_2_3x_fast... [1] https://www.anandtech.com/show/16759/sponsored-post-keep-your-apps-memory-safe-with-arm-memory-tagging-extension-mte https://www.anandtech.com/show/16759/sponsored-post-keep-you...
  - kaba0 4y ago
    I really like the ideas behind Vale, but I don’t understand this: “These adjustments mean we never need the heap which is a big improvement” Why would the heap be problematic? It is not different from the stack, there is nothing different between the stack and the heap from the perspective of the CPU. Memory locality is what matters - if you allocate an arena and fill it tightly and refer to elements in it in a predictable manner it will be just as fast.

avgcorrection 4y ago

Don’t save the disclaimer for last.

verdagon 4y ago
Happy to oblige, edited it upward. Hope your day is going well =)
- avgcorrection 4y ago
  It is, and thanks!

zozbot234 4y ago

The real disclaimer should perhaps be that this stuff is something that's still being worked on wrt. production use, just like many other kinds of PL research. Once it's ready, Rust will probably be in a very good position to adopt these features.

verdagon 4y ago
That would be pretty cool! I'm not sure Rust can support these features, though. * Generational References involve some pretty deep compiler support. One can implement something like it in Rust with a thread-local side table, but with >3x overhead compared to language-supported generational references. * Higher RAII requires that a language not treat destructors and panic handlers as the same thing. Unfortunately, Rust uses one function (drop) for both. Additionally, it would be a backwards-incompatible change; Rust generic parameters already assume a zero-arg drop() is available for all parameters, even though there's no trait bound declared for them. * Regions get most of the borrow checker's optimizing power with a fraction of the user complexity. Having both borrow checking and regions would just be adding complexity though, which defeats the purpose a bit. Still, there are a few other features of Vale that we're thinking of proposing to Rust, especially around concurrency, determinism, and better memory safety guarantees.

tomp 4y ago

I've been following Vale's progress with interest but AFAIK as of a few months ago, it's still vapourware. Excited to learn you're nearing an actual implementation though! Let's hope it's practical!

verdagon 4y ago
If talking about regions and HGM, that's fair to say. Regions are further behind where I hoped because the latter stages are blocked on generics, and I had to take 8 months off a year ago because of some PTSD from work (long story). I acknowledge that these are excuses, and that these two features of Vale can reasonably be regarded as vaporware until we get them finished. We're over halfway done with regions, fingers crossed for September! For what it's worth, most of our innovations are actually complete and released. Generational References, Fearless FFI (minus sandboxing), and Higher RAII are all done and usable, and the Perfect Replayability proof-of-concept is finished as well. All these are in version 0.2, which can be downloaded at [0]. And if you ever want to see what we're working on, we have a "What's been happening recently" on the roadmap page [1]. Thanks for following along! [0] https://vale.dev/download https://vale.dev/download [1] https://vale.dev/roadmap https://vale.dev/roadmap
- chrissinclair 4y ago
  > I acknowledge that these are excuses I'm not privy to the story here, but taking eight months off to treat PTSD doesn't sound like an excuse to me, but a really important period of time that needed to be taken. I hope you're doing alright now, but don't let yourself go thinking that taking time to deal with something like that is an excuse for other things not happening - it's far more important. Separately, I've not checked Vale out yet, but props to you for diving in on new ways of handling memory and RAII - looks really interesting and I'll be giving the language a whirl at some point soon!
  - verdagon 4y ago
    Thanks mate, I appreciate the kind words. I try not to judge myself too harshly for taking the time off, but it does help to hear it from a kind soul such as yourself. Luckily, the PTSD isn't spilling over into my other interests (games, Vale, etc) much any more so life is steadily improving!

whizzter 4y ago

Generational References is quite a neat trick, obvious in hindsight! I assume that the general idea is that non-owners really only have "weak" references (and safety comes from the compiler warning/checking that this isn't broken). One thing though about them is that I assume the generation to be co-located with the memory? If so, then the runtime wouldn't be able to free memory back to the OS while running? (Unless implemented with a side-lookup but that would hamper runtime performance?)

verdagon 4y ago
Askin' the right questions! The generations are colocated with the objects, and we can release memory back to the OS using the virtual memory shenanigans explained in [0]. However, the design and implementation have simplified quite a bit since that article. Now: * We use these generations only for assertions on dereferencing non-owning references, and don't use them for weak references anymore. * We let malloc release memory back to the OS like normal. If the user dereferences something in a released page, we'll get a page fault instead of an assertion failure, but both are handled the same. * When the generation hits INT_MAX, we just let it overflow now instead of blacklisting the allocation forever. These adjustments mean we never need the heap which is a big improvement, and really unlocks Vale as a systems programming language. The purposeful overflowing does mean that only 99.99999998% of invalid memory accesses will halt the program, which is more than enough certainty in practice [1]. (The probability is actually higher, as we increment generations by prime numbers and won't even hit our first possible collision until well after most runs have ended.) [0] https://lobste.rs/s/sglvcc/generational_references_2_3x_faster_than#c_gqakeg https://lobste.rs/s/sglvcc/generational_references_2_3x_fast... [1] https://www.anandtech.com/show/16759/sponsored-post-keep-your-apps-memory-safe-with-arm-memory-tagging-extension-mte https://www.anandtech.com/show/16759/sponsored-post-keep-you...
- kaba0 4y ago
  I really like the ideas behind Vale, but I don’t understand this: “These adjustments mean we never need the heap which is a big improvement” Why would the heap be problematic? It is not different from the stack, there is nothing different between the stack and the heap from the perspective of the CPU. Memory locality is what matters - if you allocate an arena and fill it tightly and refer to elements in it in a predictable manner it will be just as fast.