3 ms·

When RC drops to zero it is not STW. It is stop the current thread only. And even that can be trivially solved by background deallocation. Solving latency probl

When RC drops to zero it is not STW. It is stop the current thread only. And even that can be trivially solved by background deallocation. Solving latency problem of GC is far from trivial.

pjmlp 6y ago
As if stop the current thread isn't the world the world in single threaded programs. I explicitly mentioned how moving into a background thread is poor man's tracing GC. Languages like D and C# offer mechanisms for deterministic deallocation, while keep the productivity of a tracing GC.
- orneryostrich 6y ago
  But if your program is single-threaded, you don’t need an `Rc` type. The whole point of `Rc` and `std::shared_ptr` is so an object can have one owning pointer per thread, in cases where you’re not sure which thread will finish using the object last.
  - pjmlp 6y ago
    Sure you do, try to implement a Gtk-rs application without the Rc<RefCell<>> dance for widgets state.
- pkolaczk 6y ago
  Finalizers (IDisposable) or try-with-resources are not equally strong as deterministic destruction in C++ or Rust. Or did you mean a different feature for deterministic destruction in C# that I don't know of? I'm quite curious.
  - pjmlp 6y ago
    You can stack allocate objects, so those are alive just until the end of the stack. Then there native memory allocation and safe handles. IDisposable and Finalizers aren't the same thing, actually, although they happen to be used together as means to combine deterministic destruction alongside GC based destruction. You can also make use of lambdas or implicit IDisposable implementations via helper methods, that generate code similar to memory regions or arenas in C++, but in .NET. Finally, many tend to forget that .NET was designed to support C++ as well, so it is also possible to generate MSIL code that ensures deterministic destruction RAII style, naturally this falls into a bit more advanced programming, but it can be hidden away in helper classes.
    - algorithmsRcool 6y ago
      > You can stack allocate objects, so those are alive just until the end of the stack. Well, not really. You cannot stack allocate anything but primitive buffers. So no objects or even strings. So it cannot replace heap allocation for anything but smallish "arrays" of simple types like char and int. This also means you can't use normal structs/value types, only primitives. > You can also make use of lambdas or implicit IDisposable implementations via helper methods, that generate code similar to memory regions or arenas in C++, but in .NET. > Finally, many tend to forget that .NET was designed to support C++ as well, so it is also possible to generate MSIL code that ensures deterministic destruction RAII style, naturally this falls into a bit more advanced programming, but it can be hidden away in helper classes. I'm pretty sure there is no way in C# or in MSIL to explicitly free/deallocate a heap allocated object. MSIL defines a Newobj opcode, but no Freeobj or anything like it that I have ever seen. You can use custom allocators or unmanaged memory to deterministically allocate and free buffers of structs/values types. But only those that do not include references to managed object references, otherwise you would need to pin and the references yourself and keep the GC aware that there were non-tracked references to those objects. It gets messy fast.
      - pjmlp 6y ago
        It is so easy, write the code that you want in safe mode C++/CLI, get the code template, then implement the helper classes to generate the same MSIL on the fly. As for stack allocation, apparently you missed structs. Here is your string allocated on the stack. unsafe struct cppstring { const int BuffSize = 1024; fixed char data[BuffSize + 1]; int current; public cppstring(System.ReadOnlySpan<char> buffer) { for (int i = 0; i < System.Math.Min(BuffSize, buffer.Length); i++) data[i] = buffer[i]; current = 0; } } public class StackDemo { public void Myfunc() { var str = new cppstring ("Hello from stack"); } } Providing std::string like operations is left as exercise for the reader.
        algorithmsRcool 6y ago
        But that object is not a string, it is char buffer. You cannot directly substitute one for the other. Yes I realize they can be used to store the same data, but you've defined a new type that is incompatible with an actual string object.

When RC drops to zero it is not STW. It is stop the current thread only. And even that can be trivially solved by background deallocation. Solving latency problem of GC is far from trivial.

pjmlp 6y ago

As if stop the current thread isn't the world the world in single threaded programs. I explicitly mentioned how moving into a background thread is poor man's tracing GC. Languages like D and C# offer mechanisms for deterministic deallocation, while keep the productivity of a tracing GC.

orneryostrich 6y ago
But if your program is single-threaded, you don’t need an `Rc` type. The whole point of `Rc` and `std::shared_ptr` is so an object can have one owning pointer per thread, in cases where you’re not sure which thread will finish using the object last.
- pjmlp 6y ago
  Sure you do, try to implement a Gtk-rs application without the Rc<RefCell<>> dance for widgets state.
pkolaczk 6y ago
Finalizers (IDisposable) or try-with-resources are not equally strong as deterministic destruction in C++ or Rust. Or did you mean a different feature for deterministic destruction in C# that I don't know of? I'm quite curious.
- pjmlp 6y ago
  You can stack allocate objects, so those are alive just until the end of the stack. Then there native memory allocation and safe handles. IDisposable and Finalizers aren't the same thing, actually, although they happen to be used together as means to combine deterministic destruction alongside GC based destruction. You can also make use of lambdas or implicit IDisposable implementations via helper methods, that generate code similar to memory regions or arenas in C++, but in .NET. Finally, many tend to forget that .NET was designed to support C++ as well, so it is also possible to generate MSIL code that ensures deterministic destruction RAII style, naturally this falls into a bit more advanced programming, but it can be hidden away in helper classes.
  - algorithmsRcool 6y ago
    > You can stack allocate objects, so those are alive just until the end of the stack. Well, not really. You cannot stack allocate anything but primitive buffers. So no objects or even strings. So it cannot replace heap allocation for anything but smallish "arrays" of simple types like char and int. This also means you can't use normal structs/value types, only primitives. > You can also make use of lambdas or implicit IDisposable implementations via helper methods, that generate code similar to memory regions or arenas in C++, but in .NET. > Finally, many tend to forget that .NET was designed to support C++ as well, so it is also possible to generate MSIL code that ensures deterministic destruction RAII style, naturally this falls into a bit more advanced programming, but it can be hidden away in helper classes. I'm pretty sure there is no way in C# or in MSIL to explicitly free/deallocate a heap allocated object. MSIL defines a Newobj opcode, but no Freeobj or anything like it that I have ever seen. You can use custom allocators or unmanaged memory to deterministically allocate and free buffers of structs/values types. But only those that do not include references to managed object references, otherwise you would need to pin and the references yourself and keep the GC aware that there were non-tracked references to those objects. It gets messy fast.
    - pjmlp 6y ago
      It is so easy, write the code that you want in safe mode C++/CLI, get the code template, then implement the helper classes to generate the same MSIL on the fly. As for stack allocation, apparently you missed structs. Here is your string allocated on the stack. unsafe struct cppstring { const int BuffSize = 1024; fixed char data[BuffSize + 1]; int current; public cppstring(System.ReadOnlySpan<char> buffer) { for (int i = 0; i < System.Math.Min(BuffSize, buffer.Length); i++) data[i] = buffer[i]; current = 0; } } public class StackDemo { public void Myfunc() { var str = new cppstring ("Hello from stack"); } } Providing std::string like operations is left as exercise for the reader.
      - algorithmsRcool 6y ago
        But that object is not a string, it is char buffer. You cannot directly substitute one for the other. Yes I realize they can be used to store the same data, but you've defined a new type that is incompatible with an actual string object.