3 ms·
Lack of extra RAM and power to run GC is not the problem. The problem is that GC makes code behavior not predictable.
by takeda 10y ago
Lack of extra RAM and power to run GC is not the problem. The problem is that GC makes code behavior not predictable.
- pron 10y agoThat's not true in general. I've used realtime Java in a safety critical hard realtime application (running on a large server), with strong deadline guarantees (we're talking microsecond range). If you have the power and RAM to spare, the predictability issue is more cheaply solved with the approach I mentioned above (by cheaply I mean in terms of development costs; it is more costly than "plain" GC in terms of effort, but still cheaper than the Rust approach). The only real cost of GC these days is RAM (and power).
- nickpsecurity 10y agoWhich VM did you use for that out of curiosity?
- pron 10y agoSun's Java Real-Time System. It is no longer supported, AFAIK, and I don't know which RT JVM the project has switched to because I'm no longer there (my guess would be IBM's).
- naasking 10y agoThat's not true, some GC algorithms make code behaviour unpredictable. Real-time tracing GCs exist. Reference counting is GC too, but it too is unpredictable.
- nickpsecurity 10y agoReal-time GC's exist. Look up Aonix's Java stuff for what embedded or predictable apps do. Or JamaicaVM below. For enterprise, Azul has some amazing GC tech plus Java CPU's (Vega's). http://www.ptc.com/developer-tools/perc http://www.ptc.com/developer-tools/perc https://www.aicas.com/cms/en/JamaicaVM https://www.aicas.com/cms/en/JamaicaVM
- Matthias247 10y agoHowever that's not something that is automatically solved by manual memory management. Using malloc/free on a desktop OS does also not provide a predictable runtime behavior, although unexpected pauses might be smaller than with most GCs. The safest bet for predictable memory management and latency is the approach that is used by lots of embedded and realtime software: Don't allocate at all. Or at least don't do it in critical phases.
- dbaupp 10y agoI think this is the point that is obscured when discussing "manual memory management" vs "GC" languages and just focusing on the behaviour/life-cycle of an individual allocation: the former generally provide tools and features that make easier/more natural to avoid allocations, whereas the latter makes the assumption that allocation is usually OK (which is, of course, a perfectly acceptable trade-off for the domains those languages target).