5 ms·

Doesn't .NET (and C# with it) have stop-the-world GC, very similar to Java? Or do you mean something else?

pjmlp 7y ago
CLR was designed for multiple languages execution models, including C++. In what concerns C#, besides GC, you get access to off heap unamaged allocations, low level byte manipulations, value types, inlined vector allocations, stack allocation, struct aligments, spans. All GCs have eventually to stop the world, but they aren't all made alike, and it is up to developers to actually take use of the language features for writing GC-free code.
- yellowapple 7y ago
  > All GCs have eventually to stop the world Not entirely true. Erlang's BEAM definitely doesn't need to (unless you define "world" to be a single lightweight process). Perl6's MoarVM apparently doesn't need to, either.
  - pjmlp 7y ago
    Yes, I do define it like that, there is always a stop, even pauseless collectors actually do have a stop, even if a few microns. Doing it in some local context is a way to minimize overall process impact. Just like reference counting as GC algorithm does introduce pauses, specially if implemented in a naive way. More advanced ones end up being a mini tracing GC algorithm. Regardless, having any form of automatic memory management in system languages is something that should have already become standard by now.
    - yellowapple 7y ago
      There's always a stop, yes, but there's not always a stop of the whole world, which is my point. "Stop the world" implies (if not outright definitionally means - explies?) that the execution of all threads (lightweight or otherwise) stops while the garbage collector runs - e.g. that of (the official/reference implementations of) Python and Ruby. Erlang doesn't require stopping the world because every Erlang process is isolated from the others (no shared state at all, let alone mutable shared state). I don't know off-hand how Perl avoids it.
- nimmer 7y ago
  > All GCs have eventually to stop the world Not at all. Nim is an example.

CLR was designed for multiple languages execution models, including C++. In what concerns C#, besides GC, you get access to off heap unamaged allocations, low level byte manipulations, value types, inlined vector allocations, stack allocation, struct aligments, spans. All GCs have eventually to stop the world, but they aren't all made alike, and it is up to developers to actually take use of the language features for writing GC-free code.

yellowapple 7y ago
> All GCs have eventually to stop the world Not entirely true. Erlang's BEAM definitely doesn't need to (unless you define "world" to be a single lightweight process). Perl6's MoarVM apparently doesn't need to, either.
- pjmlp 7y ago
  Yes, I do define it like that, there is always a stop, even pauseless collectors actually do have a stop, even if a few microns. Doing it in some local context is a way to minimize overall process impact. Just like reference counting as GC algorithm does introduce pauses, specially if implemented in a naive way. More advanced ones end up being a mini tracing GC algorithm. Regardless, having any form of automatic memory management in system languages is something that should have already become standard by now.
  - yellowapple 7y ago
    There's always a stop, yes, but there's not always a stop of the whole world, which is my point. "Stop the world" implies (if not outright definitionally means - explies?) that the execution of all threads (lightweight or otherwise) stops while the garbage collector runs - e.g. that of (the official/reference implementations of) Python and Ruby. Erlang doesn't require stopping the world because every Erlang process is isolated from the others (no shared state at all, let alone mutable shared state). I don't know off-hand how Perl avoids it.
nimmer 7y ago
> All GCs have eventually to stop the world Not at all. Nim is an example.