4 ms·

Finally some new ideas for AOT compiled languages that don't devolve to "what if we just have memory bugs some of the time?"

by iopq 3y ago

reilly3000 3y ago
I have a new favorite HN comment :)
JonChesterfield 3y ago
Generational references leak if a counter reaches int_max and involve an increment on alloc and on free. Seems pretty close to reference counting to me. https://verdagon.dev/blog/generational-references https://verdagon.dev/blog/generational-references Statically eliminating memory operations does seem to be a win though.
- foota 3y ago
  My understanding is that this has some benefits over reference counting, though it it similar. Part of the issues with reference counting is that they are shared, meaning that it needs to be atomically incremented and decremented whenever you make a new reference (for instance in C++ if you return a shared_ptr or similar). Generational references though instead track something as a part of the value you pass around, meaning that it has better locality and doesn't suffer from contention. Copying references is assumed to be more frequent than allocating and freeing, so this is a win.
- flohofwoe 3y ago
  Typically that slot is disabled on overflow, so that no more objects can be created at that slot / memory location, which avoids the handle collision. The slot could be recycled at specific points in the code when it is certain that no more handles for this slot are out in the wild (not sure if Vale does that) (Or possibly the whole region could be discarded once it was running full, and the physical memory recycled at a new virtial address. There's plenty of virtual address space to burn through when not limited to 32 bits)
- Tuna-Fish 3y ago
  > Generational references leak if a counter reaches int_max With 64-bit counters, that's never going to happen. Alloc/free costs more than a nanosecond, and there are lot more than one element that you will be allocating, but even if you somehow managed to reallocate the same object a billion times a second, it would take over 500 years to run out of indexes.
  - pulse7 3y ago
    What about if you reach 100 billion times a second (maybe with 128 cores) and have a long running system? Maybe in this case 128-bit or 96-bit counters are better...
    - jeremyjh 3y ago
      Is it even physically possible to allocate memory that fast?
    - slashdev 3y ago
      If your program is allocating so much that you can exhaust a 64bit counter, you have a seriously bad program plus a serious memory leak. Exhausting the counter would be the least of your worries. Practically speaking you could never allocate memory that fast, a memory allocation is going to be well over 1000ns on average. Then there's the little matter of address space. Pointers on x64 are limited to 47 bits, meaning that if even you had a magical memory allocator with no book-keeping overhead, and all your allocations were 1 byte, you'd run out of pointers first. The actual virtual memory space is limited further on many operating systems, but you're still always going to be well short of 64bits.
      - dmytrish 3y ago
        Memory is meant to be reused, "64 bit counter will be enough for everybody" is not how systems programming works.
        nyanpasu64 3y ago
- pxeger1 3y ago
  Reference counting involves an increment every time a reference is shared. That's a lot more overhead than just on alloc and free - in particular, it involves going to main memory (or using part of the cache) a lot more in order to change the ref counts. Whereas on alloc and free, those frames have to fetched anyway (at least in my understanding of how memory allocators work)
- klabb3 3y ago
  Ref counts have cycles, which cause leaks (in this universe). But I digress. Overhead like increments only matters on hot paths, which are very few. The Python + C stack for ML is a manifestation of this truth. Having ergonomics of a “regular language” (affects all code) and the ability to optimize for performance (hot paths only) and stay in the same language is what I’m excited about.
renox 3y ago
Uh? While generational reference are memory safe your program still crash when there is a memory issue.. It's much better than going on in a corrupted state but still it's a crash.
- iopq 3y ago
  Better than giving away all your secrets, a crash is great in comparison

Finally some new ideas for AOT compiled languages that don't devolve to "what if we just have memory bugs some of the time?"

by iopq 3y ago

Finally some new ideas for AOT compiled languages that don't devolve to "what if we just have memory bugs some of the time?"

reilly3000 3y ago

I have a new favorite HN comment :)

JonChesterfield 3y ago

Generational references leak if a counter reaches int_max and involve an increment on alloc and on free. Seems pretty close to reference counting to me. https://verdagon.dev/blog/generational-references https://verdagon.dev/blog/generational-references Statically eliminating memory operations does seem to be a win though.

foota 3y ago
My understanding is that this has some benefits over reference counting, though it it similar. Part of the issues with reference counting is that they are shared, meaning that it needs to be atomically incremented and decremented whenever you make a new reference (for instance in C++ if you return a shared_ptr or similar). Generational references though instead track something as a part of the value you pass around, meaning that it has better locality and doesn't suffer from contention. Copying references is assumed to be more frequent than allocating and freeing, so this is a win.
flohofwoe 3y ago
Typically that slot is disabled on overflow, so that no more objects can be created at that slot / memory location, which avoids the handle collision. The slot could be recycled at specific points in the code when it is certain that no more handles for this slot are out in the wild (not sure if Vale does that) (Or possibly the whole region could be discarded once it was running full, and the physical memory recycled at a new virtial address. There's plenty of virtual address space to burn through when not limited to 32 bits)
Tuna-Fish 3y ago
> Generational references leak if a counter reaches int_max With 64-bit counters, that's never going to happen. Alloc/free costs more than a nanosecond, and there are lot more than one element that you will be allocating, but even if you somehow managed to reallocate the same object a billion times a second, it would take over 500 years to run out of indexes.
- pulse7 3y ago
  What about if you reach 100 billion times a second (maybe with 128 cores) and have a long running system? Maybe in this case 128-bit or 96-bit counters are better...
  - jeremyjh 3y ago
    Is it even physically possible to allocate memory that fast?
  - slashdev 3y ago
    If your program is allocating so much that you can exhaust a 64bit counter, you have a seriously bad program plus a serious memory leak. Exhausting the counter would be the least of your worries. Practically speaking you could never allocate memory that fast, a memory allocation is going to be well over 1000ns on average. Then there's the little matter of address space. Pointers on x64 are limited to 47 bits, meaning that if even you had a magical memory allocator with no book-keeping overhead, and all your allocations were 1 byte, you'd run out of pointers first. The actual virtual memory space is limited further on many operating systems, but you're still always going to be well short of 64bits.
    - dmytrish 3y ago
      Memory is meant to be reused, "64 bit counter will be enough for everybody" is not how systems programming works.
      - nyanpasu64 3y ago
pxeger1 3y ago
Reference counting involves an increment every time a reference is shared. That's a lot more overhead than just on alloc and free - in particular, it involves going to main memory (or using part of the cache) a lot more in order to change the ref counts. Whereas on alloc and free, those frames have to fetched anyway (at least in my understanding of how memory allocators work)
klabb3 3y ago
Ref counts have cycles, which cause leaks (in this universe). But I digress. Overhead like increments only matters on hot paths, which are very few. The Python + C stack for ML is a manifestation of this truth. Having ergonomics of a “regular language” (affects all code) and the ability to optimize for performance (hot paths only) and stay in the same language is what I’m excited about.

renox 3y ago

Uh? While generational reference are memory safe your program still crash when there is a memory issue.. It's much better than going on in a corrupted state but still it's a crash.

iopq 3y ago
Better than giving away all your secrets, a crash is great in comparison