3 ms·

To be fair soft-realtime systems don't interact well with GC's since random multi-millisecond pauses break everything. There is at least work towards making co

by Guvante 11y ago

To be fair soft-realtime systems don't interact well with GC's since random multi-millisecond pauses break everything. There is at least work towards making controlled GC pauses a possibility.

pron 11y ago
> random multi-millisecond pauses break everything Then either use a GC that doesn't have multi-millisecond pauses, or make sure your "plain" GC doesn't. Both approaches are used very commonly.
- Guvante 11y ago
  It is hard to have a discussion about GC's in the super abstract because object pools are better than GC's and even malloc. Without additional details about what the implementation will look like it is impossible to know the best memory allocation mechanism is. I was just pointing out that most GC's that are general purpose have 2-3 ms pauses for collection which is a no-go for soft-realtime systems. I did not say that GC's are incompatible with soft-realtime systems.
  - pron 11y ago
    > because object pools are better than GC's Object pools and GCs do different things, and you can have object pools in both GCed environments as in manually-managed ones, and they'd work equally the same. But note that you need a very, very good (and far from trivial) object pool to beat a good GC in multithreaded environments. > I was just pointing out that most GC's that are general purpose have 2-3 ms pauses for collection which is a no-go for soft-realtime systems. Well, most free ones. If you're writing a soft-realtime system with stricter latency requirements you'll either work harder to avoid the GC or pay for a low-latency one.
pjmlp 11y ago
> To be fair soft-realtime systems don't interact well with GC's since random multi-millisecond pauses break everything. Like these ones? http://www.atego.com/de/products/atego-perc/ http://www.atego.com/de/products/atego-perc/ Used for this? http://mil-embedded.com/news-id/?21468= http://mil-embedded.com/news-id/?21468=
- Guvante 11y ago
  Deterministic garbage collection is a completely different beast than what most people call GC. It is not a nearly magical fairy that lets you have infinite memory. Also IIRC aviation has incredibly strict rules on freeing during flight, so this likely switches to a fixed memory model for at least part of the time.
  - pjmlp 11y ago
    You aren't allowed to free at all in avionics. In Ada deallocattion requires use of the unsafe package and in SPARK dynamic allocation it isn't even possible. However the usage of GC based systems by the military in their weapon control systems, shows that there are GC implementations that able to cover certain types of real time use. After all a GC pause during a battle situation is probably not something one wishes for.

by Guvante 11y ago

To be fair soft-realtime systems don't interact well with GC's since random multi-millisecond pauses break everything. There is at least work towards making controlled GC pauses a possibility.

pron 11y ago

> random multi-millisecond pauses break everything Then either use a GC that doesn't have multi-millisecond pauses, or make sure your "plain" GC doesn't. Both approaches are used very commonly.

Guvante 11y ago
It is hard to have a discussion about GC's in the super abstract because object pools are better than GC's and even malloc. Without additional details about what the implementation will look like it is impossible to know the best memory allocation mechanism is. I was just pointing out that most GC's that are general purpose have 2-3 ms pauses for collection which is a no-go for soft-realtime systems. I did not say that GC's are incompatible with soft-realtime systems.
- pron 11y ago
  > because object pools are better than GC's Object pools and GCs do different things, and you can have object pools in both GCed environments as in manually-managed ones, and they'd work equally the same. But note that you need a very, very good (and far from trivial) object pool to beat a good GC in multithreaded environments. > I was just pointing out that most GC's that are general purpose have 2-3 ms pauses for collection which is a no-go for soft-realtime systems. Well, most free ones. If you're writing a soft-realtime system with stricter latency requirements you'll either work harder to avoid the GC or pay for a low-latency one.

pjmlp 11y ago

> To be fair soft-realtime systems don't interact well with GC's since random multi-millisecond pauses break everything. Like these ones? http://www.atego.com/de/products/atego-perc/ http://www.atego.com/de/products/atego-perc/ Used for this? http://mil-embedded.com/news-id/?21468= http://mil-embedded.com/news-id/?21468=

Guvante 11y ago
Deterministic garbage collection is a completely different beast than what most people call GC. It is not a nearly magical fairy that lets you have infinite memory. Also IIRC aviation has incredibly strict rules on freeing during flight, so this likely switches to a fixed memory model for at least part of the time.
- pjmlp 11y ago
  You aren't allowed to free at all in avionics. In Ada deallocattion requires use of the unsafe package and in SPARK dynamic allocation it isn't even possible. However the usage of GC based systems by the military in their weapon control systems, shows that there are GC implementations that able to cover certain types of real time use. After all a GC pause during a battle situation is probably not something one wishes for.